From: Chusslove Illich <caslav.ilic@gmx.net>
Subject: Avoiding name clashes between different scripts
Date: Fri, 1 Apr 2005 12:55:10 +0200 [thread overview]
Message-ID: <200504011255.13338.caslav.ilic@gmx.net> (raw)
[-- Attachment #1.1: Type: text/plain, Size: 2061 bytes --]
Hi folks,
I am trying to introduce Guile for scripting some things within, eh, a
certain C++ application. Some of these scripts, written by different
people, would come bundled with the app, and users could build their
scripts on top.
One (of many :) questions that I haven't been able to resolve yet, is what
mechanism to use to avoid name clashes in top level defines? I would like
to avoid forcing script writers to use unique prefix for defines as in C,
something like namespaces in C++ would be preferable.
Some specialties of the intended use might be helpful:
(1) Distributed scripts can be of arbitrary complexity, but user scripts
would normally be just calls to single functions within distributed
scripts, and in any case no more than few lines of code. In that light, I
wouldn't like heavy syntax for users to use namespace separations.
(2) The app itself can provide a sensible default namespace for each user
script, so ideally users wouldn't have to bother with namespaces at all,
unless they need something from other namespace. But when they do need it,
I'd like that they must name it (no automatic resolution in case of
unambiguous situation).
(3) I wouldn't even mind completely disabling users to use other than
default namespace if that would cut down the syntax in user scripts, since
users and writers of distributed scripts would actually be well connected.
(4) While namespaces would be fine, consider this about just prefixing top
level defines: prefixes could be very well defined (no need for anyone to
think what to use) and consisting of only two to three letters. Together
with (2) and (3), I might settle to a universal single character prefix,
to be replaced by suitable real prefix by the application before user
script is executed.
This was my attempt to shrink the problem to general considerations, but if
you would like the full story, it is here:
http://caslav.gmxhome.de/writings/ktranscript.html
--
Chusslove Illich (Часлав Илић)
[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]
[-- Attachment #2: Type: text/plain, Size: 140 bytes --]
_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user
next reply other threads:[~2005-04-01 10:55 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-01 10:55 Chusslove Illich [this message]
2005-04-01 12:47 ` Avoiding name clashes between different scripts Thien-Thi Nguyen
2005-04-01 14:57 ` Chusslove Illich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200504011255.13338.caslav.ilic@gmx.net \
--to=caslav.ilic@gmx.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).