Greetings all.

I just stumbled upon some limitations in the POV language and thought
of a way they could be avoided. These limitations are:

-you can't pass a macro as a parameter of another macro
-POV can't evaluate an expression to a float when reading from a file

The solution I have in mind is a parse(string) function. It simply
inserts the string in the code at the time of parsing (as include
files and macros are treated). So you can to something like:

#macro lissagousFunction(a,b,c)
 ...
#end

#macro connectTheDots(func, foo1, foo2)
 ...
 thisAndThis = parse(func);
 ...
#end

connectTheDots ("lissagousFunction(3,0,1)", 5, 1)

Does it make sense?


Peter Popov
ICQ: 15002700

Post a reply to this message

Peter Popov wrote:
> 
> Greetings all.
> 
> I just stumbled upon some limitations in the POV language and thought
> of a way they could be avoided. These limitations are:
> 
> -you can't pass a macro as a parameter of another macro
> -POV can't evaluate an expression to a float when reading from a file
> 
> The solution I have in mind is a parse(string) function. It simply
> inserts the string in the code at the time of parsing (as include
> files and macros are treated). So you can to something like:
> 
> #macro lissagousFunction(a,b,c)
>  ...
> #end
> 
> #macro connectTheDots(func, foo1, foo2)
>  ...
>  thisAndThis = parse(func);
>  ...
> #end
> 
> connectTheDots ("lissagousFunction(3,0,1)", 5, 1)
> 
> Does it make sense?
> 
> Peter Popov
> ICQ: 15002700

  Me being the programming and math illeterate bofo that I am I really
don't understand what you are trying to say but I think I understand
what you are trying to accomplish none the less. Instead of the approach
you are suggesting could you not instead store the data produced by the
first macro in an array and use that to pass to the function in the
connectTheDots macro ?


P.S. There is a nice connect the dots macro available at Twyst's MacroScope
collection if you are interested.

http://macroscope.twysted.net/

-- 
Ken Tyler

mailto://tylereng@pacbell.net

Post a reply to this message

All you have to do is write the string to a file and then include the
file. A macro could be made to do this, and use the same syntax.

Post a reply to this message

On Mon, 12 Jul 1999 14:04:02 -0500, Chris Huff wrote:
>All you have to do is write the string to a file and then include the
>file. A macro could be made to do this, and use the same syntax.

Good idea.  The only caveat, of course, is you wouldn't be able to
parse strings that contain calls to the parse macro.  That might not
be too big a deal, though.

Post a reply to this message

>Good idea.  The only caveat, of course, is you wouldn't be able to
parse strings that contain calls to the parse macro.  That might not
be too big a deal, though.<

Why not? Macros are capable of recursion, and it would be possible to
set it up to use different files for each macro call, wouldn't it?

Post a reply to this message

The way the parser is currently written, this would not be trivial to
add, IMHO.  Chris' suggestion is good, though (although maybe a bit slow?).

-Nathan


Peter Popov wrote:
> 
> Greetings all.
> 
> The solution I have in mind is a parse(string) function. It simply
> inserts the string in the code at the time of parsing (as include
> files and macros are treated). So you can to something like:

Post a reply to this message

The way I am currently doing it is the way Chris offers. The problem
is that I need a good 20000 or more calls of this kind, and it gets
slow, really.

Anyway, for the purpose I need it, I should confine to official POV
only, so that's the only way to go right now. Thank you guys.


Peter Popov
ICQ: 15002700

Post a reply to this message

On Mon, 12 Jul 1999 22:29:15 -0400, Nathan Kopp wrote:
>The way the parser is currently written, this would not be trivial to
>add, IMHO.  Chris' suggestion is good, though (although maybe a bit slow?).

Funny you should say that.... Before I read Chris' suggestion, I went
to see how hard it would be to implement and it didn't look too 
difficult to do at least the nonrecursive case.  OTOH, it wouldn't be 
much faster than Chris' suggestion, so why make changes to the code?

Post a reply to this message

Peter Popov wrote:
> 
> The way I am currently doing it is the way Chris offers. The problem
> is that I need a good 20000 or more calls of this kind, and it gets
> slow, really.
> 
> Anyway, for the purpose I need it, I should confine to official POV
> only, so that's the only way to go right now. Thank you guys.
> 
> Peter Popov
> ICQ: 15002700


Perhaps using a temporary file can speed things up. Working on a unix
box, this would be on a ram disk, skipping all the hard disk handling.

Axel

Post a reply to this message

Yes, a RAM disk(that term is also used on the Mac) would definitely
better here. (now why didn't I think of that?)

Funny how different platforms use completely different language for the
exact same thing. (I like folder better than directory, though.)

Post a reply to this message