Weird Language Features

Neil Madden nem00u at cs.nott.ac.uk
Sun Feb 18 11:58:04 EST 2001


Dave Cross wrote:
> 
> [Please watch the replies on this message as it's heavily
> cross-posted]
> 
> I'm doing some comparisons on programming language features and I'd be
> very interested to know how you would handle the following scenarios
> in your programming language of choice.
> 
> 1/ The programmer calls a function that doesn't actually exist within
> the application (or libraries). Is the a feature whereby the
> programmer can create a "catch-all" function which is called in cases
> like these? Can this function examine the list of existing functions
> and call the most appropriate one? Or create a new function on the fly
> and install it into the application?

Tcl has the "unknown" procedure that is called when the interpreter
doesn't recognize a command. From the Tcl help pages:

"If the Tcl interpreter encounters a command name for which there is not
a defined command, then Tcl checks for the existence of a command named
unknown. If there is no such command, then the interpreter returns an
error. If the unknown command exists, then it is invoked with arguments
consisting of the fully-substituted name and arguments for the original
non-existent command. The unknown command typically does things like
searching through library directories for a command procedure with the
name cmdName, or expanding abbreviated command names to full-length, or
automatically executing unknown commands as sub-processes. In some cases
(such as expanding abbreviations) unknown will change the original
command slightly and then (re-)execute it. The result of the unknown
command is used as the result for the original non-existent command."
(<URL: http://dev.scriptics.com/man/tcl8.4/TclCmd/unknown.htm>)

It is left up to the application programmer to implement this, so you
could have an unknown procedure that does the things you mention above.

See also: <URL: http://mini.net/cgi-bin/wikit/495.html>) for some
examples.


> 
> 2/ Can ou filter the input source code before compilation (or
> interpretation) in some way so that language keywords could be changed
> for other strings? Imagine you wanted to allow someone to program your
> language of choice in, say, French. How would you go about translating
> French keywords into ones that the compiler (or interpreter) could
> understand. What if the translation wasn't one-to-one or fixed? Could
> you put enough intelligence into the translator so that it could
> handle certain strings differently depending on where they appeared in
> the source code?

There are no reserved words in Tcl, so all keywords can be overwritten
or renamed. Using the unknown command above, you can put as much
intelligence as you want into interpreting a command. Although, this
seems like a fairly dangerous thing to do, as any packages or extensions
you used would have to know that the keywords had all been changed! But
once again, you could allow the [unknown] handler to map commands onto
their new names.

> 
> If you're wondering why I'm inventing these bizarre scenarios, it's
> for a paper I'm writing for this year's Perl Conference.  Perl does
> have these features (see the AUTOLOAD function and source filters) and
> I'm interested in seeing how widespread they are in other languages.
> 
> Of course, if you'd like to tell me just why you consider it's a good
> thing that your language of choice doesn't have these features, then
> I'd be only too happy to hear that too.
> 
> I'd just like to make it clear that I'm not interested in getting into
> "my language is better than your language" types of flamewars. I'm
> certainly not trying to argue that Perl is better than other languages
> for having these features.
> 
> Thanks for your time.
> 
> Dave...
> 
> --
> <http://www.dave.org.uk>  SMS: sms at dave.org.uk

-- 
--------------------------------------------------------------
Neil Madden.
neil at tallniel.co.uk                       nem00u at cs.nott.ac.uk
http://www.tallniel.co.uk     http://www.cs.nott.ac.uk/~nem00u
--------------------------------------------------------------



More information about the Python-list mailing list