Nieminen Juha wrote:

> Axel Baune <aba### [at] neuroinformatikuni-ulmde> wrote:
> : As I've never looked into the Code for the PoV-Parser I' did"t know
> : exactly, but I've already written a parser of my own for my programms,
> : and therefore I know what effects it would have on my own parser if I
> : wish to include the new syntax. From this knowledge I've extrapolated to
> : the PoV-Parser.
>
>   Perhaps you didn't do it the right way ;)
>
>   Using something like yacc and lex makes it quite easy to add new syntax.
> Although povray doesn't use them, it might use something similar (I really
> don't know).

Well, using something like XML rules would make it much easier to parse.
Unfortunately POV-Ray's language and parser are not designed quite that way.
After the change for 4.0, maybe it will end up a little more extensible.

--
"My new computer's got the clocks, it rocks
But it was obsolete before I opened the box" - W.A.Y.

Post a reply to this message

An evolution to a Basic like syntax would be OK.

Object Oriented - heaven help us!!  The programmers (some) might like this
but I think the rest of us casual users would be driven away.

--
Jim

Check out my web site  http://www.kressworks.com/

Ken <tyl### [at] pacbellnet> wrote in message
news:38C7685C.5A4F3A68@pacbell.net...
>
>
> Greetings,
>
>   As we all know the language used by POV-Ray is not only easy to use
> but offers a lot of flexibility. There are often many ways to describe
> an object or attribute of an object because of the "looseness" of
> it's language.
>
>  Now many in the past have argued that it is too primitive for thier
> needs and suggest that it become more of an official programming
> language. They also suggest it should become more object oriented
> or stricter rules should be applied to the language from what it is
> now. Some say the syntax is too loose for all practical purposes.
> Some even suggest it should move to a binary format that needs to
> be compiled before being parsed (heaven forbid).
>
>  I say the one thing that attracted me to POV-Ray was the fact that
> it's text based input was both easy to learn, was intuitive from the
> beginning, and I never had to learn a programmers language to use
> the program. I like the way that you can describe something in several
> ways to achieve the same results. In my opinion this loose and very
> flexible language makes it a very powerful program to use.
>
>  What I do worry about though is the influence that the people who seek
> a more programmer like language may have for the mass of people that have
> no programming background but still enjoy using the program. It might
> be good for them in some circumstances but would it be good for everyone
> is not so cut and dried as it were.
>
>
> So the questions I have are really for the non-programmer types out there.
>
> Would you have difficulty re-learning POV-Ray if it's language format
> changed ?
>
> Would you resent it or maybe even quit using the program completely ?
>
>
>
> P.S. I am not suggesting that the POV-Team is even considering changing
>      the language at this time. I am mearly trying to find out what the
>      mainstream users of the program think about this and if they really
>      like the way the syntax is currently structured.
>
>
> --
> Ken Tyler -  1300+ Povray, Graphics, 3D Rendering, and Raytracing Links:
> http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

Jim Kress wrote:

> An evolution to a Basic like syntax would be OK.
>
> Object Oriented - heaven help us!!  The programmers (some) might like this
> but I think the rest of us casual users would be driven away.

No. No. Really. OO for POV-Ray would be nice.

Trust me.  :-)


In all seriousness, object oriented would work very well for POV-Ray, since it
models... objects!

If you are hand-coding POV-Ray, then you have to start thinking about the
objects you are making, primitives, meshes, etc. and where they go and how they
interact and what properties they have...

It's already a little OO, but going more so in the proper manner (notice I just
said "in the proper manner") might help greatly.


For those who learn other types of programming first, OO gets a little
difficult to pick up. But I believe that in general learning OO as a first
language is easier.

There are cases where an OO language might not be appropriate, but since the
concepts in POV-Ray are already so similar, it makes OO a good choice for
POV-Ray. Many of the concepts that make learning an OO language 'more
difficult' than learning VB are concepts that need to be learned for POV-Ray
itself.

OO was also used by Macromind in their Lingo in Director. Director was
definitely not for programmers but for designers. For their needs, it was very
good.

--
"My new computer's got the clocks, it rocks
But it was obsolete before I opened the box" - W.A.Y.

Post a reply to this message

Chris Huff wrote in message ...
>In article <38C992EA.4C6238BD@ij.net>, Matt Giwer <jul### [at] ijnet>
>wrote:
>> Next, complex conditional if then else statements. Can GOTO be
>> far behind?
>
>Umm, we have if-then-else statements. And switch statements. And goto is
>a bad idea for many reasons.


In "The Art of Computer  Programming", Knuth uses a GOTO in one of the
algorithms, simplifying things greatly.

Mark

Post a reply to this message

Mark Wagner wrote:

> Chris Huff wrote in message ...
> >In article <38C992EA.4C6238BD@ij.net>, Matt Giwer <jul### [at] ijnet>
> >wrote:
> >> Next, complex conditional if then else statements. Can GOTO be
> >> far behind?
> >
> >Umm, we have if-then-else statements. And switch statements. And goto is
> >a bad idea for many reasons.
>
> In "The Art of Computer  Programming", Knuth uses a GOTO in one of the
> algorithms, simplifying things greatly.
>
> Mark

And that was one out of how many? And by a 'Master' also. Only for the
advanced.   :-)

--
"My new computer's got the clocks, it rocks
But it was obsolete before I opened the box" - W.A.Y.

Post a reply to this message

"Axel Baune" <aba### [at] neuroinformatikuni-ulmde> wrote in message
news:38C8DC47.1BEAFE1C@neuro.informatik.uni-ulm.de...
>
> Johannes Hubert wrote:
> >
> >
> > For example:
> >
> > for (I = 1; I <= something; ) {
> >     // loop body here
> >     I += non_deterministic_increment;
> > }
>
> From the viewpoint of a computer scientist (I'm one) this is a not a
> syntactically correct defiend for-loop.

Since we seem to look at details now (not to say beginning to split
hairs), I have to point out, that you are wrong: The "for" loop is
syntactically absolutely correct (in the languages C, C++, Java at
least) - on the *syntax* level there is nothing wrong with it.

However:

> Sorry for flaming, but this are the programming styles, which make
> software packages difficult to maintain, debug, readable and
> understandable by other programmers.

With this I may agree. I have never (as far as I can remember) actually
used a loop like this. I would rather use a while-loop for stuff like
that.
The point was to shows that a C/C++/Java style for-loop *can* change its
looping index.

Johannes.

Post a reply to this message

"Axel Baune" <aba### [at] neuroinformatikuni-ulmde> wrote in message
news:38C8DAB2.3BE14CC3@neuro.informatik.uni-ulm.de...
>
> No, I don't think so. In most programming languages the state of the
> variables used in a for-loop are undefined outside the loop, but most
> programmers ignores this and use the mostly undocomented feature, that
> after the for-loop the variable has the value of the variable in the
> last loop incremented by the specified step.

Not really correct either. You are probably thinking of C++, where the
ISO/ANSI standard says that a variable declared (and initialized) inside
of the for-statement is defined only in the statement and the block that
belongs to it. A fact that is still ignored by most compilers (the
standard is still kind of fresh).

But:

This is true only for for-loops like this one:

    for (int i = start; i != end; i++) {
    }

If you rewrite the loop like this:

    int i;
    for (i = start; i != end; i++) {
    }

then there is no ambiguity about if or if not "i" is defined after the
loop and which value it has. It *is* defined and *has* the value
assigned to it during the last executed operation that modified it.

Johannes.

Post a reply to this message

"Jim Kress" <jim### [at] kressworkscom> wrote in message
news:38c9cb32@news.povray.org...
> An evolution to a Basic like syntax would be OK.
>
> Object Oriented - heaven help us!!  The programmers (some) might like
this
> but I think the rest of us casual users would be driven away.

I must agree with Jon (see his post). Your message shows a "fear" of the
conecept of "object oriented" that is totally unfounded.
I guess it is porbably mostly fueled by the fact that OO is such a
buzzword, and by (not very good) programmers that have learned
procedural programming and or now too afraid, too lazy or too snobbish
to learn something else, and thus give OO a stigma of "new and complex
and difficult to learn, with no real advantages" just to justify the
fact that they don't even want to look at it.

I am convinced that learning OO programming is in many cases easier than
learning procedural programming (if you are not already "spoiled" by a
procedural language) - and for POV OO would be perfect - easy to
understand and learn and very powerful.

I'm very interested how Mikael's work will turn out. Maybe POV-Ray will
go the way of C++? (meaning *not* that the language becomes like C++,
but that it will be an object oriented language that contains backwards
compatibility to the old language, like C++ contains good old C).

Greetings,
Johannes.

Post a reply to this message

Gilles Tran wrote:

> Of course I don't want to be conservative : POV can (should) evolve.
> But my personal wish list is made of features that would make the
> user's life easier in terms of creation (like a really

> support of some popular mesh formats, or a simple way to make
> patina and cracks, or built-in "fur" and "tree" engines etc.).

Here I will definitely agree with you. I would like to see procedural
features added that ease the creation of scene building without having
to resort to adding difficulty to the language itself. If you look at
the wealth of plug-ins available for 3DS Max you will see that they
offer some powerful features, that are easy to use, and the functions
that make them work are transparent to the user. The question that
needs to be asked is if the program exists for programmers or if it
exists for users who don't care how it works so long as it does.

> I have to recognize that some programming features (like arrays
> or macros) that seemed complex at the beginning (yes, for a
> non-programmer, even arrays are complex !) proved themselves
> very useful. My current concern, which I seem to share with
> Ken Tyler, is that many of features I've seen on programmers'
> "wish lists" looked like they would surely improve the lives
> of programmers and possibly make pov faster, or more flexible,
> but that they would also make a few non-programmers cringe.
> For instance, some people may have fun browsing a 500-page
> long manual on OO programming, some others don't.

Good point(s). What I also fear is that if the programming language
is extended in POV-Ray to include OO programming, for () loops, and
all of the other programming suggestions that have been addressed
in this thread, is what is going to happen when some non programming
literate POV-User comes to the news groups seeking help and some
programmer type gives them an example in the form of these new
features ? The programmer types (and there a lot of them here in the
groups that answer questions on a regular basis) will quickly adopt
the attitude that everyone thinks like them and give examples in
their language style of choice, while the real truth of the matter
is that they could express themselves in a way that the people
seeking help will not understand a word they are saying.

> To answer Ken's questions, I surely would experience trouble if
> the language changed completely.

I would probably not use the new version if it became to hard to
learn. This would restrict me to using the older versions of the
program and I would miss out on new features.

> I've got my own legacy of scenes
> (which already hard to maintain due to version changes and
> immoderate patch use), and I'm able to work fast because I
> know my way in POV (provided the help file is open !).
> So having a new language format would be like using a
> new software : I would take the trouble to learn it only if
> it was clearly "competitive", in terms of user-friendliness
> and features, over the current POV implementation.

I agree here too. I have more .pov files that you can shake a stick
at and I am comfortable now, after hundreds of hours of using the
program, with it's current language structure.

-- 
Ken Tyler -  1300+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

I understand your arguments and can see how many of them may be true.

However, I am not really convinced. It *may* be true that creating a
more stringent and defined "language" may scare away users. However, I
don't know if this has to be so. If the language is designed carefully,
with "non-programmer" users in mind, it may become more accessible.
This doesn't necessarily have to mean that the new language resembles
any given programming language. It could be defined in its very own way
instead.

I have the impression, that the POV-Script has (in places) grown from
some ad-hoc decisions, and is therefore (in places) bloated and not very
logical.
Example: The fact that many keywords begin with a "#". This is a typical
sign for that the person who designed the initial language and parser
did not really know too much about parsers (I hope I am not stepping on
too many toes here, because I am speculating...) The "#" makes the
keywords easier to find for the parser, an approach intuitive for many
people who are confronted with writing a parser for the first time and
don't know better. However, parser technology has for a long time been
very advanced, and there is really no need for such "crutches" to make
parsing easier.
Note: I am not saying that POVs parser is bad, since it has had a long
time to evolve. I am only pointing out the "#" as a thing that has
probably been introduced ad-hoc in one of the very first versions, and
has since been carried with the language, without having much effect
besides making the script harder to read. An example for the "bloat" I
mentioned.

I agree with Ken's assessment that it is nice to have so many different
ways to achieve the same thing. I like that too. However, to have this,
there is no need for a bloated language. Take Java for example: Newly
designed and relatively "lean" it still offers many ways to do the same
thing (and I am *not* advocating to make the POV-Script like Java! this
is just an example...).

I think that "cleaning out the undergrowth" in the language (and adding
some OO features on the way) can have positive effects both for the
"programmer" and "non-programmer" users,
_if_done_in_a_carefully_thought_through_way_!
The "programmers" will find themselves more at home in the POV-language,
and the old problem of the difficulty to parse POV-Script (no program
besides POV really can) would also be solved.
And the "non-programmers" would get a language for which the manual
would actually be *thinner* than it is now, a language that is more
approachable and easier to learn (because frankly I think, that many of
you here who advocate POV-Script as an easy language to learn have lost
perspective a bit, since you alreay *know* POV-Script: sure, newbies
*can* learn POV-Script, but the language is far from being easy to learn
and could be much more so in my opinion).

The key is: Such a redesign of the language must be very well thought
through. A quick-shot solution (with focus only on making POV more like
a "standard" programming language) is not a good solution. And also
backwards compatibility to the old script needs to be maintained, so
that the old scenes are not lost in limbo.

So far,

Johannes.

Post a reply to this message