[Date Index] [Thread Index] [Author Index]

Re: UpValues for expressions headed by a string

• To: mathgroup at smc.vnet.net
• Subject: [mg62925] Re: UpValues for expressions headed by a string
• From: dh <dh at metrohm.ch>
• Date: Thu, 8 Dec 2005 03:27:35 -0500 (EST)
• References: <dn8fra$bof$1@smc.vnet.net>
• Sender: owner-wri-mathgroup at wolfram.com

Hi Trevor,
You can only assign an upvalue to en expression with the Head: Symbol.
You can not assign an upvalue to an expression with Head: String.
Therefore, unprotecting string will not help.

I think it is a bad idea to use strings as headers for data types 
instead of Symbol. I do not see any benefit, it only makes things more 
complicated. If you need to convert a string to a symbol, you may always 
use:
Symbol["string_name"]

Daniel

Trevor Baca wrote:
> This is a question about the limitations of using a string as the head
> of an expression.
> 
> As an example we'll create two expressions (or data types): a foo
> (which does what we want) and a bar (which doesn't).
> 
> If we define foo with
> 
>   fooQ[f_] := MatchQ[f, foo[_Integer]]
> 
> and then define wiggle on foo with
> 
>   foo /: wiggle[f_foo?fooQ] := First[f] + 10
> 
> then the results are exactly as expected:
> 
>   wiggle[foo[17]]
>   27
> 
> But, if we (note the doublequotes and) define bar as headed with a
> string in
> 
>   barQ[b_] := MatchQ[b, "bar"[_Integer]]
> 
> and then attempt to define wiggle on bar with
> 
>   "bar" /: wiggle[b_"bar"?barQ] := First[b] - 5
> 
> we get the error
> 
>   TagSetDelayed::"sym": "Argument "bar" at position 1 is expected to be
> a symbol.
> 
> which makes sense because we're essentially trying to assign an upvalue
> to the *string* "bar" (rather than to the *symbol* foo).
> 
> First question: is it possible to assign an upvalue to a string?
> 
> Second question: why doesn't unprotecting String with
> 
>   Unprotect[String];
>   "bar" /: wiggle[b_"bar"?barQ] := First[b] - 5;
>   Protect[String]
> 
> work?
> 
> Last, is it, in general, a bad idea to create data types headed with a
> string, either because of situations like the one given here or for
> some other, additional reasons?
> 
> Trevor.
>