Weird Language Features

Neil Madden nem00u at cs.nott.ac.uk
Sun Feb 18 18:29:27 EST 2001


BTW. I think that the problems you have posed are very much "scripting"
solutions rather than system programming solutions. In other words,
scripting languages (perl, python, tcl) are likely to be able to solve
these fairly easily, whereas compiled languages are going to find it
harder. If you posted scenarios involving intensive maths computation
the results might be the other way around :-). If you are writing a
paper, compare like to like...

Neil Madden wrote:
> 
> 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
> --------------------------------------------------------------

-- 
--------------------------------------------------------------
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