Axiom interpreter semantics of == in parameters
Bill Page
I just wanted to mention something here that I just learned about how
the Axiom interpreter handles option arguments. When discovering how
the 'draw' operations in Axiom processes optional arguments, e.g.
draw(sin(x), x=1..10, title=="sin function")
I realized the interpreter does something rather clever but probably
quite unexpected. The problem is that (unlike Aldor) SPAD does not
provide built-in support for calling functions with optional
arguments. Instead what it does is collect all the arguments
containing == into a List *and* then it applies the name to the left
of == as a function to the value on the right. So much to my surprize:
(1) -> (x+->x)(sin==x,cos==y)
(1) [sin(x),cos(y)]
Type: List Expression Integer
is equivalent to:
(2) -> (x+->x)([sin(x),cos(y)])
(2) [sin(x),cos(y)]
Type: List Expression Integer
The list of optional arguments is always passed as the last argument
to the function. This is completely general so one can write for
example:
(3) -> ((x,y)+->[x,y])(sin==x,n,cos==y)
(3) [n,[sin(x),cos(y)]]
Type: List Any
What do you think? Do you like that, or is this something that should
be implemented in a deeper way?
Regards,
Bill Page.
Gabriel Dos Reis
| panAxiom developers,
|
| I just wanted to mention something here that I just learned about how
| the Axiom interpreter handles option arguments. When discovering how
| the 'draw' operations in Axiom processes optional arguments, e.g.
|
| draw(sin(x), x=1..10, title=="sin function")
Hmm, I thought I already mentioned this in discussions with Ralf ;-/
|
| I realized the interpreter does something rather clever but probably
| quite unexpected.
It is the post parser doing it. And I don't like it -- the irony is
that I made Boot do the same.
| The problem is that (unlike Aldor) SPAD does not
| provide built-in support for calling functions with optional
| arguments. Instead what it does is collect all the arguments
| containing == into a List *and* then it applies the name to the left
| of == as a function to the value on the right. So much to my surprize:
Quite disgusting, no?
|
| (1) -> (x+->x)(sin==x,cos==y)
|
| (1) [sin(x),cos(y)]
|
| Type: List Expression Integer
|
| is equivalent to:
|
| (2) -> (x+->x)([sin(x),cos(y)])
|
| (2) [sin(x),cos(y)]
|
| Type: List Expression Integer
|
| The list of optional arguments is always passed as the last argument
| to the function. This is completely general so one can write for
| example:
|
| (3) -> ((x,y)+->[x,y])(sin==x,n,cos==y)
|
| (3) [n,[sin(x),cos(y)]]
|
| Type: List Any
|
| What do you think? Do you like that, or is this something that should
| be implemented in a deeper way?
I don't like it: For example, I cannot '==' to mean `definition' in
expressions -- but I already had that debate with Ralf.
-- Gaby
Bill Page
>
> Bill Page writes:
>
> | panAxiom developers,
> |
> | I just wanted to mention something here that I just learned about how
> | the Axiom interpreter handles option arguments. When discovering how
> | the 'draw' operations in Axiom processes optional arguments, e.g.
> |
> | draw(sin(x), x=1..10, title=="sin function")
>
> Hmm, I thought I already mentioned this in discussions with Ralf ;-/
>
Sorry I missed it. Can you please tell me wihich list? When?
> |
> | I realized the interpreter does something rather clever but probably
> | quite unexpected.
>
> It is the post parser doing it. And I don't like it -- the irony is
> that I made Boot do the same.
>
> | The problem is that (unlike Aldor) SPAD does not
> | provide built-in support for calling functions with optional
> | arguments. Instead what it does is collect all the arguments
> | containing == into a List *and* then it applies the name to the
> | left of == as a function to the value on the right. So much to
> | my surprize:
>
> Quite disgusting, no?
>...
Weird at least, but oddly effective as a representatio. Too bad it
increases the distance between the interpreter and compiler languages.
> | What do you think? Do you like that, or is this something that
> | should be implemented in a deeper way?
>
> I don't like it: For example, I cannot '==' to mean `definition'
> in expressions -- but I already had that debate with Ralf.
>
Perhaps it would be better to provide a function to which == maps, e.g.
x == y ==> OPTARG(x,y)
which does by default what the interpreter wants for now but which
allows customization?
Regards,
Bill Page.
Francois Maltey
draw(sin(x), x=1..10, title=="sin function")
I [Bill] realized the interpreter does something rather clever but
probably quite unexpected.
I don't find it so clever. I understand only after your mails that this
== isn't the definition of the function title, but a trick about lists
of arguments.
And [Gaby] I don't like it :
The problem is that SPAD does not provide built-in support for calling
functions with optional arguments.
I don't like this ==, too.
Axiom operates over one list of arguments when there are a lot of
arguments, try :
concat ([1,2], [3,4]) or concat [[1,2],[3,4],[5,6]].
The second concat is reduce (concat, L, []).
It may be useful to have a lot of functions as this one :
min / max / horizConcat / vertConcat / + / * and remain reduce only for
the rare cases.
draw(sin(x), x=1..10, title=="sin function")
all theses optional parameters might occur in a list :
draw(sin(x), x=1..10, [title="sin function"]), draw(sin(x), x=1..10, []) or
draw(sin(x), x=1..10, [title="sin function", numberOfPoints = 100,
drawAxes=false, viewWindows=[-%pi..%pi,-1..1]])
The type of this list contains terms of a new domain OptionalParameters,
described by :
identificator = an Any object, it looks like other cas...
F.
Bill Page
>
> Gabriel and Bill discuss about :
>
> draw(sin(x), x=1..10, title=="sin function")
> all theses optional parameters might occur in a list :
>
> draw(sin(x), x=1..10, [title="sin function"]),
> draw(sin(x), x=1..10, []) or
> draw(sin(x), x=1..10, [title="sin function", numberOfPoints = 100,
> drawAxes=false, viewWindows=[-%pi..%pi,-1..1]])
>
> The type of this list contains terms of a new domain
> OptionalParameters, described by :
> identificator = an Any object, it looks like other cas...
>
If you wish, you can call the Axiom draw command in the manner you
describe above, avoiding the use of ==
draw(sin(x), x=1..10, [title("sin function")),
draw(sin(x), x=1..10, [])
draw(sin(x), x=1..10, [title("sin function"), var1Steps(100),
clip(false), range([-%pi..%pi,-1..1])])
There is no need to invent a new type of parameter, although not all
options in your example seem to be available.
Regards,
Bill Page.
Ralf Hemmecke
> "Bill Page" <bill...@newsynthesis.org> writes:
>
> | panAxiom developers,
> |
> | I just wanted to mention something here that I just learned about how
> | the Axiom interpreter handles option arguments. When discovering how
> | the 'draw' operations in Axiom processes optional arguments, e.g.
> |
> | draw(sin(x), x=1..10, title=="sin function")
>
> Hmm, I thought I already mentioned this in discussions with Ralf ;-/
Actually, I don't remember such that we talked about such behaviour as
Bill described. I must have misunderstood you.
> | I realized the interpreter does something rather clever but probably
> | quite unexpected.
>
> It is the post parser doing it. And I don't like it -- the irony is
> that I made Boot do the same.
>
> | The problem is that (unlike Aldor) SPAD does not
> | provide built-in support for calling functions with optional
> | arguments. Instead what it does is collect all the arguments
> | containing == into a List *and* then it applies the name to the left
> | of == as a function to the value on the right. So much to my surprize:
>
> Quite disgusting, no?
>
> |
> | (1) -> (x+->x)(sin==x,cos==y)
> |
> | (1) [sin(x),cos(y)]
If that is the behaviour. I really agree with Gaby. It's not what I
would like.
Ralf
Gabriel Dos Reis
Sorry for the late reply -- I have been `on the road' for more than
three weeks (no, not vacation).
"Bill Page" <bill...@newsynthesis.org> writes:
| On Fri, Jun 27, 2008 at 4:59 AM, Gabriel Dos Reis wrote:
| >
| > Bill Page writes:
| >
| > | panAxiom developers,
| > |
| > | I just wanted to mention something here that I just learned about how
| > | the Axiom interpreter handles option arguments. When discovering how
| > | the 'draw' operations in Axiom processes optional arguments, e.g.
| > |
| > | draw(sin(x), x=1..10, title=="sin function")
| >
| > Hmm, I thought I already mentioned this in discussions with Ralf ;-/
| >
|
| Sorry I missed it. Can you please tell me wihich list? When?
This discussion happened on the open-axiom-devel list, under the
thread 'rep, per and Union' you started.
In that message you even expressed surprised at hearing of 'OPTARG'
from the interpreter when you used '==' in an expression context.
Then, I explained in
how the interpreter handles '==' depeending on the context meaning
either definition or default argument. The rest is essentially the
discussion with Ralf I was referring to when I explaing why I dislike
that behaviour.
Ralf found that behaviour intuitive and sees no problem.
http://sourceforge.net/mailarchive/message.php?msg_name=482EF252.5020402%40hemmecke.de
http://sourceforge.net/mailarchive/message.php?msg_name=482F1FCA.4080309%40hemmecke.de
[...]
| > | What do you think? Do you like that, or is this something that
| > | should be implemented in a deeper way?
| >
| > I don't like it: For example, I cannot '==' to mean `definition'
| > in expressions -- but I already had that debate with Ralf.
| >
|
| Perhaps it would be better to provide a function to which == maps, e.g.
|
| x == y ==> OPTARG(x,y)
|
| which does by default what the interpreter wants for now but which
| allows customization?
Well, '==' is a token, not operator.
-- Gaby
Ralf Hemmecke
> |
> | x == y ==> OPTARG(x,y)
> |
> | which does by default what the interpreter wants for now but which
> | allows customization?
>
> Well, '==' is a token, not operator.
Gaby, why not asking Stephen Watt? He should know about why == is used
both for definitions as in
A: T == V
and as optional arguments as in
foo(b: Integer == 1): T == ...
^^
or in calling
foo(b==2)
Stephen, you can find more information about this discussion in a recent
post of Gaby.
Stephen, could you also comment on why in Axiom == is used as in
>| (1) -> (x+->x)(sin==x,cos==y)
>|
>| (1) [sin(x),cos(y)]
?
Ralf