Re: SyntaxInformation and OptionsPattern
- To: mathgroup at smc.vnet.net
- Subject: [mg112745] Re: SyntaxInformation and OptionsPattern
- From: Leonid Shifrin <lshifr at gmail.com>
- Date: Wed, 29 Sep 2010 04:13:09 -0400 (EDT)
Hi David,
here is my guess:
SyntaxInformation is supposed to work at the "read-time" for our code, and
by that
time in general it can not know that an additional argument is not an
option. I mean,
in the case f[x,y,z], it may be that z contains an option (z = aaa->bbb,
e.g.), so it
should not be marked, or it will irritate the developer who uses this style
of
programming.
For the case of a number (like 3) or generally something immutable and
obviously
not an option (say, also strings, special Locked symbols, I don't actually
know what else),
this looks like it has been overlooked. I wonder however how hard would it
be to
implement it for these cases. May be not that hard, but I have no idea.
As a side remark, I personally would very much welcome a greater
programmatic control
over the syntax coloring than that available now. For example, I sometimes
roll out some
special-purpose scoping construct which behaves in some ways differently
from the available
built-in ones, and I would love to be able to syntax-color the variables it
localizes.
Regards,
Leonid
On Tue, Sep 28, 2010 at 2:05 PM, David Park <djmpark at comcast.net> wrote:
> Here is a slightly modified example from the SyntaxInformation Function
> page:
>
>
>
> Options[f] = {aaa -> 1, bbb -> 2};
>
>
>
> SyntaxInformation[
>
> f] = {"ArgumentsPattern" -> {_, _, OptionsPattern[]}};
>
>
>
> f[x, y, 3, aab -> 2]
>
>
>
> The "3" is clearly not an Option, and it exceeds the allowed number of
> arguments - so why isn't it flagged in Red?
>
>
>
>
>
> David Park
>
> djmpark at comcast.net
>
> <http://home.comcast.net/~djmpark> http://home.comcast.net/~djmpark/
>
>
>