>Alain: That is NOT exactly what I am suggesting, Uli.
>I was suggesting that we create some FreeCard stacks
>whose fields correspond to the data and metadata
>necessary to specify new vocabulary, rules, etc .. for
>the FreeCard interpreter. There would be no FreeScript
>involved, except to make these 'techie' stacks as user
>friendly as any other FC stack.
Ah!
That I didn't think of at all. We could allow creating some less strict
syntax, I think that should be relatively efficient. E.g. we could have
some way to declare a handler name and certain "prepositions" like in
AppleScript. Just so I don't have to write until my fingers bleed, an
off-the-top spontaneous and still very rough around the edges example how
this could be done:
remap "look up %1 in %2 (using method %3)" to "lookUp"
This would then allow writing
look up "Menus" in Help
look up "Scroll Bars" in QuickRef using method "fastlookUp"
and these would simply result in handler calls
lookUp "Menus",Help
lookUp "Scroll Bars",QuickRef,"fastlookUp"
Or instead of a "remap" command we could have that list in a special file
that is global to all of FreeCard (this would be a good way to implement
the "dial" command using the "play" command, e.g.). This is by no means a
syntax proposal, but merely a demonstration that it *would be* feasible.
>Alain: The same approach has-been and could-be used to
>create external commands and functions. We don't give
>a hoot about the "procedure entryPoint" and all of
>that, but we do know what we want our command to be
>named...
I think declaring or writing XCMDs in FreeScript is rather useless, as the
advantage of XCMDs and other plug-ins is exactly that you can link to
another language. Of course, a command like the above "remap" could be used
to give more comprehensible syntax to plug-in commands. I guess that's what
you wanted to say, right?
>Alain: Do they have to play with the source-code? Or
>are we going to offer them a user-friendly stack-based
>front-end to "remove what they don't need"? Further,
>it might be interesting to build-in some FreeScript
>macros into this front-end .. to simplify, speed-up,
>etc .. the process of removing un-needed parts.
Playing with the source code will be the initial way to do it, but later
there could be a tool that removes certain parts if we make them very
modular. However, this is rather tricky as some platforms do not allow
executable code to reside in anything other than an application or a shared
library. This means we'd either have to write ugly platform-specific hacks
that rip parts out of the application, or we'd have to split FreeCard into
hundreds of separate files of which you then remove the ones you're not
using. I'm sure we'll find a way to allow some degree of customization, but
it probably won't be that you have a dialog where you can select the
commands to include on a per-command basis. It'll have to be bigger
"packages", like entirely removing sound support.
>for the record, however, I believe that it
>is an error to obsessively focus on speed to the
>detriment of rapid prototyping, flexibility, etc ...
I think Anthony will make only sane choices when it comes to optimizing
speed. But in this case the problem is that the basic concept has to be
effective. It's like the difference between my two attempts at an
Interpreter, Joker and Velocity. Velocity's concept was ineffective from
the beginning, which is why I could have optimized all I want, it still
would have been much slower than the completely rewritten Joker.
>Alain: There is hope then. His feedback on this idea
>of mine was more favorable than yours, Uli. And
>Adrian's parser is also a possibility ;-)
Hmmm... Adrian's parser is written in HyperTalk, right?
>Alain: Each stack could have its own stacksInUse, and
>menubar too while we are at it.
I thought about this, too, but there are several problems:
1) HyperCard compatibility -- it simply doesn't work this way in HC
2) User Interface Guidelines -- The menu bar really shouldn't swap in and
out menus depending on the frontmost window.
3) Stacks used as plug-ins -- How is a stack supposed to e.g. install its
own menus (like Color Tools' "Color" menu) if it can only change its own
menu bar?
I'm still not sure how we could fix this, but at the moment I'm leaning
towards just keeping our 100% HyperCard promise. If our users then say,
"Fine, we have HyperCard but we'd really like you to change this" we can
still choose to change this for FreeCard 1.1. However, we could add special
properties that control this behaviour, i.e. in "Protect Stack..." we could
have an option to ignore stacks start-used by other stacks or to preserve
the menu bar on suspendStack and restore it on resumeStack etc. I think
having this as per-stack flags will make much more sense while still
fulfilling our 100% promise.
>It would allow one to
>switch contexts quickly and efficiently. The
>alternative is to jam all of the un-related handlers
>(e.g. different contexts) into a generic set of
>stacksInUse that all stacks share. That's not very
>modular (e.g. spaghetti-like).
This is definitely a valid point.
>Alain: I hope you are right. 100% HC-compatibility
>requires it, eh! But it is not a foregone conclusion,
>that's for sure, judging by past debates on this
>subject.
HyperCard externals will be in the Macintosh release. I already have the
code (XFromApp, I think it's also in a folder on the UFP server). However,
since Macintosh XCMDs don't port too well I think we'll create a new
cross-platfrom extension standard, and Scott has already said he'd be
interested in having a common standard for FC and MC. We'll decide that
when either Scott chooses to add it to MetaCard or when FreeCard arrives at
this stage.
>Alain: This is the fundamental drawback of using any
>hierarchy. Code is distributed at several levels, and
>"unexpected results by wrong handler being triggered"
>inevitably becomes an unfortunate possibility that has
>to be debugged by tracing through the execution.
However, while it remains in a relatively short hierarchy which you filled
with handlers yourself this won't be a problem. However, if we have dozens
of stacks stuffing their handlers in front, you might be surprised if you
rely on certain messages being passed through. This local stacksInUse
concept definitely sounds like a viable solution here.
>Alain: Absolutely! User-defined properties are the way
>to go. So you don't have just one container for the
>stack ... you have as many containers as you want! And
>no external files, no hidden parts, etc. Clean and
>automatic. You gotta love it!
I do :-)
Cheers,
-- M. Uli Kusterer
------------------------------------------------------------
http://www.weblayout.com/witness
'The Witnesses of TeachText are everywhere...'
