Nicolas Alvarez wrote:

>> Anyway, my request isn't based on how easy or hard it would be to 
>> implement,
>> but rather on how useful it would be to me.  In the past year, I've run
>> across more and more situations where I would want this.
>>
>>
> 
> Name some. Maybe we don't need an eval()-like function, what we need is 
> other features so that we never ever need to use eval.

In my case I was using POV-Ray as a graphing calculator and wanted the 
resultant image to show both the text and graphic form of the function. 
   I wanted to only have to enter a function in SDL once, so I used a 
string, and figured out the include-file-method as a workaround to 
convert that string to something plot-able.  I asked on the newsgroups 
if there was a better way... wishing.
Charles

Post a reply to this message

> Nicolas Alvarez wrote:
>>
>> Name some. Maybe we don't need an eval()-like function, what we need 
>> is other features so that we never ever need to use eval.
> 
> In my case I was using POV-Ray as a graphing calculator and wanted the 
> resultant image to show both the text and graphic form of the function. 
>   I wanted to only have to enter a function in SDL once, so I used a 
> string, and figured out the include-file-method as a workaround to 
> convert that string to something plot-able.  I asked on the newsgroups 
> if there was a better way... wishing.
> Charles


#declare F = function { x*2 };
#declare Ftext = f.toString(); // <-- that's probably the feature you need

Or a way to convert a string to a function; note that's still not an 
eval(), as it would be limited to only mathematical expressions.

Post a reply to this message

Charles C <"nospam a nospam.com"> wrote:
>    I wanted to only have to enter a function in SDL once, so I used a 
> string, and figured out the include-file-method as a workaround to 
> convert that string to something plot-able.  I asked on the newsgroups 
> if there was a better way... wishing.

  I wouldn't say that's the best possible usage for an eval() function...

-- 
                                                          - Warp

Post a reply to this message

Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:
> #declare F = function { x*2 };
> #declare Ftext = f.toString(); // <-- that's probably the feature you need

  That wouldn't preserve the exact original representation (because
functions are byte-coded, thus dropping the original function string
completely).

-- 
                                                          - Warp

Post a reply to this message

Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:
> Name some. Maybe we don't need an eval()-like function, what we need is
> other features so that we never ever need to use eval.

I want to tie various strings together using concat() and then evaluate it.

This is certainly possible by writing to temporary include files, but it
would be simpler (and easier) for the artist to simply call parse (eval is
already a keyword).

Post a reply to this message

Warp wrote:
> Charles C <"nospam a nospam.com"> wrote:
>>    I wanted to only have to enter a function in SDL once, so I used a 
>> string, and figured out the include-file-method as a workaround to 
>> convert that string to something plot-able.  I asked on the newsgroups 
>> if there was a better way... wishing.
> 
>   I wouldn't say that's the best possible usage for an eval() function...

I don't understand your meaning.  I'd guess that somebody might say that 
fishing is not the best possible use of fishing line but if somebody 
actually said that I'd say it begs the question what they thought would 
be a better use.  Anyway, I think Ben was suggesting a general ability 
to parse strings, not specifically evaluate an expression.  I was giving 
an example where I wanted to use the same data in two disparate ways and 
found a clumsy way to avoid cut/pasting.  I think it would be great if 
strings could be treated almost as if they were include files in memory, 
with their own name-space locality etc.  You couldn't  #include 
StringIdentifier because then you'd be including a file by that name, 
but #parse works for me...
Charles

Post a reply to this message

Charles C <"nospam a nospam.com"> wrote:
> Warp wrote:
> > Charles C <"nospam a nospam.com"> wrote:
> >>    I wanted to only have to enter a function in SDL once, so I used a 
> >> string, and figured out the include-file-method as a workaround to 
> >> convert that string to something plot-able.  I asked on the newsgroups 
> >> if there was a better way... wishing.
> > 
> >   I wouldn't say that's the best possible usage for an eval() function...

> I don't understand your meaning.

  That if the only rational use for eval() is so that you can display a
function as a string besides evaluating it, that's not reason enough to
make the parser 10 times more complicated just get an eval() function.

> I think it would be great if 
> strings could be treated almost as if they were include files in memory, 

  All kinds of things would be nice, but a different story is how easy
it is to implement.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Charles C <"nospam a nospam.com"> wrote:
>> Warp wrote:
>>> Charles C <"nospam a nospam.com"> wrote:
>>>>    I wanted to only have to enter a function in SDL once, so I used a 
>>>> string, and figured out the include-file-method as a workaround to 
>>>> convert that string to something plot-able.  I asked on the newsgroups 
>>>> if there was a better way... wishing.
>>>   I wouldn't say that's the best possible usage for an eval() function...
> 
>> I don't understand your meaning.
> 
>   That if the only rational use for eval() is so that you can display a
> function as a string besides evaluating it, that's not reason enough to
> make the parser 10 times more complicated just get an eval() function.

Understood.  Agreed.  It's probably not worth it just for a single 
uncommon situation if it makes the parser 10 times more complicated.* 
But maybe it's not the only rational reason, and that's what the 
discussion is for. I was contributing *a* reason.  I didn't mean for my 
reason as a stand-alone justification for a massive effort.

*I think prioritization can be measured in three dimensions: time 
urgency, importance or benefit, and ease of implementation or cost.

<stands on soap box>
All ideas are worth considering, generally**, no matter how silly,  but 
some can be ruled out earlier than others depending on cost and benefit. 
  Maybe this is one of those earlier ones.  In terms of POV-Ray features 
if enough people want a feature, then at some point it becomes worth 
considering more seriously.   Even if the benefit is low and the cost is 
high, people who believe there is a benefit should still chime in and 
say so or we'll never really know how many people it'll help or what 
different uses it might have.


**If for example you're dealing with an emergency situation I'd say go 
deal with that first.

> 
>> I think it would be great if 
>> strings could be treated almost as if they were include files in memory, 
> 
>   All kinds of things would be nice, but a different story is how easy
> it is to implement.
> 

Very true.  You don't think it would be worth it for this one.  Still, 
it doesn't hurt to talk about it to see what different people think - 
Float an idea and if it's not good, chances are it'll drift away. :-)

My 2c
Charles

Post a reply to this message

Le 26.10.2007 17:32, Chambers nous fit lire :
> Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:
>> Name some. Maybe we don't need an eval()-like function, what we need is
>> other features so that we never ever need to use eval.
> 
> I want to tie various strings together using concat() and then evaluate it.
> 
> This is certainly possible by writing to temporary include files, but it
> would be simpler (and easier) for the artist to simply call parse (eval is
> already a keyword).
> 
> 
What about, then, having 'parse(str)' as a macro (or something else
?) which:
 1/ create a temp file named automatically
 2/ write str in the file
 3/ close the temp file
 4/ include the temp file

Please note, that with current implementation of #macro (and because
str might contains such), you cannot remove the temp file before the
end of the parsing.

It's a kludge, you will need a file-garbage-collector by the end of
parsing time, but it should be rather easy with the current parser.
-- 
The superior man understands what is right;
the inferior man understands what will sell.
-- Confucius

Post a reply to this message

> Le 26.10.2007 17:32, Chambers nous fit lire :
>> Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:
>>> Name some. Maybe we don't need an eval()-like function, what we need is
>>> other features so that we never ever need to use eval.
>> I want to tie various strings together using concat() and then evaluate it.
>>
>> This is certainly possible by writing to temporary include files, but it
>> would be simpler (and easier) for the artist to simply call parse (eval is
>> already a keyword).
>>
>>
> What about, then, having 'parse(str)' as a macro (or something else
> ?) which:
>  1/ create a temp file named automatically
>  2/ write str in the file
>  3/ close the temp file
>  4/ include the temp file
> 

It already exists on the standard include file strings.inc, called 
Parse_String.

Post a reply to this message