Q: functional/equational language, smells a little of Python
Kay Schluehr
kay.schluehr at gmx.net
Sun Jun 5 04:23:42 EDT 2005
John J. Lee wrote:
> Saw this on LWN:
>
> http://q-lang.sourceforge.net/
>
>
> Looks interesting, and reminiscent of symbolic algebra systems like
> Mathematica. Also, the website mentions dynamic typing and "Batteries
> Included", which made me think of Python. Damned silly name, though
> (perhaps pre-Google?).
>
> Anybody here used it?
>
> Snippet from the FAQ:
>
>
> 2. Yet another "Haskell for the poor"?
>
> Not quite. Even though the syntax and some of the stuff in the
> standard library looks superficially similar, Q is different in a
> number of ways:
>
> * First and foremost, Q is an equational rather than just a
> functional language, meaning that it is based on general term
> rewriting instead of the lambda calculus (which is just one, and
> very special, rewriting system). In particular, Q has no a
> priori distinction between "constructors" and "defined" function
> symbols, and argument patterns are not restricted to
> "constructor terms". This allows you to have symbolic evaluation
> rules like the following distributivity rule: X*(Y+Z) =
> X*Y+X*Z. Such rules are not allowed in ML and Haskell because
> they violate the "constructor discipline". Moreover, the Q
> interpreter also happily reduces expressions involving
> variables, so that you can try your definitions with symbolic
> inputs (e.g., map F [X,Y] will evaluate to [F X,F Y]), which is
> quite useful for debugging purposes.
>
> * While other functional languages are either "eager" or "lazy", Q
> tries to give you the best of both worlds: It uses eager
> (call-by-value) evaluation by default (which lends itself to an
> efficient implementation), but also allows you to define your
> own special forms, which can be used to implement both
> call-by-name functions and lazy data constructors. Using special
> forms you can also define your own "meta functions" which
> manipulate arbitrary (not necessarily irreducible) expressions
> as literal terms. This gives you full control over the reduction
> strategy, where this is desired, as well as a kind of "macros"
> and "self-modifying programs", since constructs like lambda
> abstractions can be analyzed, transformed and constructed in
> many ways before they are actually evaluated.
>
> * Q uses dynamic typing. This has become a rare feature in
> contemporary functional languages, which usually employ a
> Hindley/Milner type system which offers more safety at the
> expense of restricting polymorphism. Q gives you back the
> flexibility of good old Lisp-style ad-hoc polymorphism and even
> allows you to extend the definition of existing operations
> (including built-in functions and operators) to your own data
> types. Moreover, Q has a Smalltalk-like object-oriented type
> system which supports data encapsulation and (single)
> inheritance. This makes it possible to manage complex,
> polymorphic data with ease.
>
> * Q takes the pragmatic route in that it provides (monad-free)
> imperative programming features such as imperative I/O and
> mutable data cells, similar to the corresponding facilities in
> ML. While one may argue about these, they certainly make life
> easier when programming complex I/O stuff such as graphical user
> interfaces.
>
> * Last but not least, the Q programming system comes with
> batteries included. There are quite a few add-on modules
> interfacing to third-party libraries which, while not as
> comprehensive as the facilities provided by traditional
> scripting languages like Perl and Python, allow you to tackle
> most practical programming problems with ease. In particular,
> multimedia and computer music is an area where Q shines,
> providing facilities to handle graphics, digital audio and MIDI
> in a convenient and efficient manner (efficient enough for soft
> realtime applications), which go well beyond what is currently
> being offered for other functional languages.
>
>
> Some of Q's flexibility comes at a price. In particular, Q's symbolic
> evaluation capabilities as a term rewriting language dictate that the
> language is essentially exception-free. This means that an
> "ill-formed" expression (such as "division by zero" or, more
> generally, the application of a function to data for which there is no
> corresponding definition) does not, by default, raise an exception,
> but instead the expression is already in "normal form", i.e., it
> evaluates to itself. As a remedy, Q provides facilities to add
> explicit error rules which raise exceptions, and to handle exceptions
> in a suitable manner. Another limitation is that Q does not allow you
> to have arbitrary local definitions in the style of Haskell and ML's
> "let" and "where" clauses. In Q, "where" clauses are limited to
> variable definitions (similar to Haskell's pattern bindings), but
> local rewriting rules are not supported as they would wreak havoc on
> the term rewriting semantics.
>
> You will also notice that Q lacks most of the syntactic sugar found in
> Haskell. This is partly due to my laziness, but it also keeps the
> language and the core system simple. Using Q's symbolic processing
> capabilities, the usual bits like lambda abstractions, pattern
> matching conditionals and list comprehensions can easily be written in
> Q itself (although this does not offer quite the same performance as
> when they are provided as builtins, of course).
>
>
> John
I'm curious why do you think that it "smells like Python"? Because of
"batteries included"? Are dotNET and Java Python-like because they come
up with a fast object library?
Personally I think that time has passed for functional languages except
for academic studies. Features like term rewriting are interesting per
se but I believe that they can be implemented on top of dynamic OO
languages like Python with some effort too. My expectation of future
Computer Algebra Systems ( CAS ) is that they provide models of
mathematical objects like algebras, sets, spaces, manifolds,
number-fields etc. that can be refined using inheritance and can be
adapted dynamically. Despite the majority of people working in CA I
think that OO is much more the way contemporary mathematicians think
about their stuff than the FP toolbox approach. What I'm missing is a
kind of domain specific syntax, e.g. a <ket|bra> syntax for working
with states in quantum mechanics. But that's out of the scope of
current Python.
Regards,
Kay
More information about the Python-list
mailing list