interface for numerical integration, roots etc

common lisp allows keyword arguments.  They look like this
(count 4 #( 1 2 3 4 5 6) :test #'<)  ;; count how many items r  in 
vector such that 4<r
(count 4 #( 1 2 3 4 5 6) :test-not  #'<)  ;; count how many items r in 
vector such that  not(4<r)..

So the keywords are part of the syntax, prefixed by colons.  The 
definition form
is fairly elaborate including optional, keyword, rest, default-values etc.

You can read up on how CL solves this particular problem perhaps by 
overkill.

I disagree with RD's comment regarding the -> syntax .


First of all, Mathematica has some visibility and popularity. It's not 
terrible to say to
a potential user that the language, say for feeding options to the 
integration program,
 looks the same in Maxima. 

It is in some sense, returning the favor. For example, Mathematica 
adopted % from Macsyma.

The rest of the syntax, though hardly exactly the same, coincides in 
lots of instances.

Secondly, when Mathematica has adapted some kind of mathematical notation to
try to make it easy to use, it is worth considering whether it is a good 
reflection
of how that notation should be written.  Sometimes it is quite clumsy, 
and should
be rejected.  Sometimes it is just fine.  WRI might object, but they 
could object
to anything.


Robert Dodier wrote:
> On Wed, May 26, 2010 at 4:33 AM, John Lapeyre <pdl at johnlapeyre.com> wrote:
>
>   
>>  highlevelfunc(blob, [x,0,1],[y,a,b], u=v, maxiterations -> 10, eq1 -> c=d);
>>  highlevelfunc(blob, [x,0,1],[y,a,b], u=v, maxiterations => 10, eq1 => c=d);
>>     
>
> I dunno. I don't see much value to adopting the notation from Mma
> since very few people will recognize it, 
Why do you say that? I think there are many people who would understand 
the notation without any
explanation whatsoever.  People who have used Mathematica or not.
> and, more importantly,
> Mma differs from Maxima in much more fundamental ways than
> syntax: it doesn't help to use the same syntax when programs are
> going to work differently anyway.
I think the programs WOULD work the same in fundamental ways.  e.g.
numerical_integrate(f, ..[x,0,1],  accuracy_goal-> 0.001,....)  in 
maxima vs.
NIntegrate[ ....]
>  Same thing goes for adopting
> notations from Maple or Matlab or whatever.
>   
I think that Matlab and Maple notations are considerably older.  I 
cannot think
of any redeeming feature in Maple notation, offhand.  Matlab has its 
problems,
but the notation for slices of arrays is compact and popular.

>   
>>  highlevelfunc(blob, [x,0,1],[y,a,b], u=v, opts(maxiterations = 10, eq1 = c=d));
>>  highlevelfunc(blob, [x,0,1],[y,a,b], u=v, opts=[ maxiterations = 10, eq1 = c=d ]);
>>     
>
> I think I like the last one there, although I would spell out "options".
> It's also OK to omit options=[...] and just put the options at the same
> level as the other arguments.
>   
I think this has problems.  consider
solve([a*x+b=c],opts=[method=default])   where there 3 instances of =, 
each meaning somewhat different things,
as well as two instances of [] meaning somewhat different things.

I prefer hlf(blob,blob2, option1->value1, ...)  or even 
hlf(blob,blob2,option1,value1, ...)

by the way,
defrule(name, lhs, rhs)  COULD be changed to

name:lhs->rhs, syntactically,  and was originally proposed that way (by 
me, to Joel Moses).  He was uncomfortable
with changing the parser (which was not extensible as it is now). 
Mathematica makes much more use of rule definition  (in fact it is the 
way most people "define functions").

RJF