lib/Funky/Details/documentation/faq.hpp

   1 /* Funky: a light-weight embeddable programming language
   2  * Copyright (c) 2007, Ronald Landheer-Cieslak
   3  * All rights reserved
   4  *
   5  * This is free software. You may distribute it and/or modify it and
   6  * distribute modified forms provided that the following terms are met:
   7  *
   8  * * Redistributions of the source code must retain the above copyright
   9  *   notice, this list of conditions and the following disclaimer;
  10  * * Redistributions in binary form must reproduce the above copyright
  11  *   notice, this list of conditions and the following disclaimer in
  12  *   the documentation and/or other materials provided with the distribution;
  13  * * None of the names of the authors of this software may be used to endorse
  14  *   or promote this software, derived software or any distribution of this
  15  *   software or any distribution of which this software is part, without
  16  *   prior written permission from the authors involved;
  17  * * Unless you have received a written statement from Ronald Landheer-Cieslak
  18  *   that says otherwise, the terms of the GNU General Public License, as
  19  *   published by the Free Software Foundation, version 2 or (at your option)
  20  *   any later version, also apply.
  21  *
  22  * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
  23  * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
  24  * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
  25  * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
  26  * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
  27  * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
  28  * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
  29  * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
  30  * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
  31  * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
  32  * POSSIBILITY OF SUCH DAMAGE.
  33  */
  34 /** \page faq Frequently Asked Questions
  35  * <dl>
  36  * <dt>Why does Funky take so long to compile?</dt>
  37  * <dd>Funky is implemented using Boost.Spirit. Spirit extensively uses
  38  *     C++'s templates, and forces your compiler to work hard for a
  39  *     living. The advantage is that the generated code is pretty close
  40  *     to optimal while the code in C++ is very close to BNF (as far as
  41  *     the grammar is concerned).</dd>
  42  * <dt>Why doesn't Funky have any support for named variables?</dt>
  43  * <dd>Funky doesn't have variables because it's a functional programming
  44  *     language and, as such, doesn't need any variables. It's a very
  45  *     different rogramming "paradigm" that you may be used to, but it
  46  *     is a very powerul one once it's well-understood.</dd>
  47  * <dt>Why does Funky only have one built-in type?</dt>
  48  * <dd>Funky doesn't support different types because there has, at least
  49  *     until now, not been a real need for them. If support for different
  50  *     types is needed, support will be added. All the necessary preparations
  51  *     for such an addition have been made when Groovy was implemented, so
  52  *     adding support for a Funky variant with more than one built-in type
  53  *     should be a trivial affair.</dd>
  54  * <dt>Why doesn't Funky support higher-order functions?</dt>
  55  * <dd>Supporting higher-order functions for installable functions (i.e.
  56  *     C++ functions you can install in the interpreter) would imply
  57  *     exposing part of the implementation, which would be relatively
  58  *     trivial to do and will be done if there's a need for it.\n
  59  *     Supporting higher-order functions within the language's scripts
  60  *     (i.e. functions that take functions as arguments and/or return
  61  *     functions) would imply a relatively small change to the grammar,
  62  *     but would introduce potential ambiguity that would only be possible
  63  *     to resolve when the script is actually run. That is not really a
  64  *     blocking problem either, so it will be implemented when the need
  65  *     arises.\n
  66  *     If you really have a need for this, contact me so we can work out
  67  *     the details of what you need (but remember that a small fee may
  68  *     apply if you want me to make modifications to this work on-demand).
  69  *     </dd>
  70  * </dl>
  71  */