> Alain: For the record, I would like to have as much
> of FreeCard in stack-form as possible. Stack-based
> tool(s) to create Xternals and/or a stack-based
> FreeCard syntax editor (e.g. augment FC's parser
> with new vocabulary or grammar).
Uli: I doubt it'll really be feasible to make the
interpreter extensible using FreeScript.
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.
Alain: Externalize the data, metadata and structure of
the changeable parts of the interpreter. Make a user
friendly front-end to it with stack(s). People like
myself use the stack. We create new cards, fill-in the
changeable parts, freeScript validates our entries and
so on, and the final output is either executable or is
a formal-spec that allows programmers to make it so.
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...
Uli: We will keep it extensible and we'll very likely
try to make it modular so people can remove the parts
they don't need...
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.
Uli: ... but if we implemented FreeScript by means of
FreeScript instead of by means of compiled code, we'd
arrive where Java is now speed-wise :-(
Alain: I understand what you are saying, and I realize
that speed is the highest-priority dev/exec
constraint. for the record, however, I believe that it
is an error to obsessively focus on speed to the
detriment of rapid prototyping, flexibility, etc ...
You know, the slow stuff! RAM is relatively cheap, and
the hardware is increasingly very fast too. Speed of
execution will take care of itself and/or could be
optimized later on in the development cycle. There is
no such quick-fix for ideas, concepts,
experimentation, innovation, flexibility, versatility,
adaptability, etc.
> Uli: However, the future is still open. Maybe
> Anthony one day ... finds a way to give you more
> extensible syntax.
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 ;-)
> Uli: We have to be careful about such things
> though, as inserting scripts into the hierarchy
> ad libitum might lead to something not unlike
> spaghetti code.
Alain: Each stack could have its own stacksInUse, and
menubar too while we are at it. 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).
> Then there are Xternals. MetaCard supports them
> on all platforms, so perhaps FC will too.
Uli: I think it's planned.
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.
> Uli: Maybe we could allow changing the hierarchy
> in a restricted way, e.g. we could add
> "set the stacksInUse to ..." and let scripters
> re-arrange start-used stacks...
Alain: That's essentially what we sought.
Uli: ... but it would be very dangerous to insert a
stack in front of the current stack or even a button
since then we might get unexpected results by the
wrong handler being triggered.
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.
> Uli: sounds like you're looking for a way to attach
> data to a stack, right? MetaCard and SuperCard have
> user properties for this, which I consider the right
> route to head there.
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!
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com
