>The debate rages on concerning the pros and cons of
>including the DO and SEND commands of HyperCard and
>SuperCard into FreeCard.
>
>I am among those that (unrealistically!!!) expect
>FreeScript to support the DO and SEND commands.
Alain,
I'm also among those who think they are both necessary. "send" will have
to be in there, but since it is usually used to send a message, we can
implement it like it's done in Serf, which allows compiling it while
retaining the current flexibility.
>1. Apple's Open Scripting Architecture comes to mind.
>Do we support several scripting languages inside our
>Script Editor? Do we support AppleScript? --
>AppleScript and MacPerl support is one of HyperCard's
>hottest features in my opinion. If we don't, then what
>do we do with HyperTalk syntax related to this
>feature?
OSA is a feature that would be nice to have, even though it's
Mac-specific. If we find someone who thinks they want to write it, I think
we can surely add it in.
>2. Do we support HyperCard's Translator Interface and
>the corresponding language property?
I'm really not sure. So far you're the only one I know that ever actually
saw it, and I know few people who ever used it. Again, if someone adds
something like this to FreeCard, I see no problem. This should be
cross-platform then, though.
>3. Do we support XCMDs and XFCNs? This is arguably
>HC's hottest feature of all. Without externals to
>augment HC's access and other capabilities, HC becomes
>much less interesting. If we don't support them, then
>what do we provide instead? As an alternative, do we
>make it ridiculously easy for users to integrate new
>code segments directly into FreeCard's source?
If we don't mess up the code, it will be pretty easy for programmers to
simply add their code segments into FreeCard's sources, recompile and have
their own FreeCard. After all, that's the reason we're doing this as open
source anyhow.
Still, we already have code to run XCMDs and XFCNs, and even their
PowerPC-native counterparts, so this will certainly be available for
Macintosh users. But in the end we'll have to add a reasonably
cross-platform plug-in architecture that only requires recompiling the
plug-in on another platform to use it there. But the specifics of this will
be decided later, possibly when we have the first release finished. And it
will certainly be discussed on the xTalk list.
>1. Is this approach viable for us ?
In part, surely. There will be platform-specific features, maybe even as
plug-ins. But the core *must* be cross-platform, as must be all features we
can simulate on other platforms. But we'll have to get the core running
before we can add in platform-specific stuff. This needs to be an organized
mess.
>2. Among the Mac-specific stuff that MacPerl provides,
>there is the Open Scripting Architecture, and most of
>the Toolbox too.
I doubt we will include the toolbox in FreeCard itself. We'll provide much
of the functionality in there via the FreeScript syntax and object model.
E.g. to create a window you'd just use the "create stack" command etc. I'm
firmly against adding things like pointers and memory management to
FreeScript. Maybe we'd put that into a stand-alone interpreter, but since
FreeScript is a very high level language, it would take away all the
advantages it might have over Perl if we do it this way.
>4. How realistic would it be to adapt MacPerl's source
>code to give us an enormous leap forward in the
>development of the Mac version of FreeCard? Or, more
>generally, to adapt Perl's source code to give us an
>enormous leap forward in the development of the core
>(multi-platform) version of FreeCard?
I doubt it would work out well. You know, you can rework a Volkswagen
until it looks like a Mercedes, but I guess it'll be more effective to buy
a Mercedes right away. An interpreter or compiler has to be written for the
language it processes. If we take one intended for a language as strict as
Perl in syntax, and try to get it to parse HyperTalk, we'd pretty much end
up with a very slow interpreter with lots of exceptions in it to handle
xTalk specifics.
Finally, I believe we already ruled out Perl's license, which makes this
an option that isn't viable anymore.
Cheers,
-- M. Uli Kusterer
------------------------------------------------------------
http://www.weblayout.com/witness
'The Witnesses of TeachText are everywhere...'
--- HELP SAVE HYPERCARD: ---
Details at: http://www.hyperactivesw.com/SaveHC.html
Sign: http://www.giguere.uqam.ca/petition/hcpetition.html
