clipka <nomail@nomail> wrote:
> Actually, I remember that when I started programming, I was multiple times
> fooled by the while-loop, about when the condition is checked. The most
> intuitive loop, for me, was:

> REPEAT
>   ...
> UNTIL (condition);

> which did exactly what I always expected it to do: Execute the list of
> statements, *then* check for the condition, and if it didn't hold true, repeat
> the whole smash over and over again.

  The problem with that is that it will execute the body always at least
once. If it should never be executed (which isn't even a rare occurrence),
you will need to add a conditional around the entire repeat-until loop,
and the condition will be a duplicate of the 'until' condition.

-- 
                                                          - Warp

Post a reply to this message

"clipka" <nomail@nomail> wrote:

>
> How about this - would these be more obvious for a non-programmer? (Be invited
> to pick your favourite or roll your own)
>
>     #for i from 0 to N-1  ...  #end
>     #with i from 0 to N-1  ...  #end
>     #foreach i in 0 to N-1  ...  #end
>
>

Cool! I get to choose a keyword for the new SDL. :-P  I feel like a contestant
on that U.S. TV game show "The Price Is Right":  "Let's see, I think I'll
choose door number...THREE.  No, wait...number FOUR!"

Actually, in looking up the definition of a #for loop, I really can't think of
an easy English-syntax equivalent. And I see that #for is a basic keyword of
almost all computer languages--so changing it would be silly, I guess.

> > Of course, I could be the 'odd-man-out'; perhaps the majority of POV-Ray
> > users *do* actually come from some kind of programming background, where
> > 'odd' syntax terms are of no consequence.
>
> .... which is not necessarily the point, because even if most POV-Ray users
> would come from a programming background, it could be *because* the syntax
> might be not obvious enough to others. Which in that case would rather speak
> in favor of making the language more intuitive to noobs.

That's an interesting point, one that I hadn't considered. And I would agree.
(I'm not sure why the SDL learning-curve didn't put ME off when I started with
POV-Ray--probably because the astounding visual results of the program just
outweighed any seeming syntax difficulties. I just *had* to learn it!
Hopefully, that's how other newbies react to the SDL as well. And it goes
without saying that POV-Ray is not for everyone--but then neither are the
plethora of other programming languages out there. You have to be willing to
take a leap into a 'new world.' And as the saying goes, "No pain, no gain.")

KW

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> clipka <nomail@nomail> wrote:
> > Just for starters: The main difference would probably be a significant increase
> > in the number of semicolons used.
>
>   I'm not liking the sound of that. I really like being able to eg. create
> lists of elements in a loop without having to worry about the commas.
> If you make the current SDL "more formalized" and "consistent", you will
> be removing a lot of its current flexibility which makes it so great.

Warp, please make up your mind: Do you want a *scripting* language, or a
*preprocessing* language?

In a preprocessing language, you indeed have to worry about the commata because
you're generating *source* code that will be parsed again.

In a scripting language, you just loop and add elements to some data container.

I thought you were so much in for render-time scripting with some VM; how on
earth are you going to do that with a preprocessing language??

>   (Also being forced to create all the necessary commas in the loop,
> except for the last element which is never followed by a comma, will
> make the resulting SDL code to be more hackish and might not, in fact,
> make it any easier to create any kind of converter from it to a new
> language.)

Now how come you're talking about commata here??

I never mentioned them.

You're over-reacting based on pure assumptions. Please keep calm and wait for
what I'll present before going on a pre-emptive strike against it, okay?

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
>
> > REPEAT
> >   ...
> > UNTIL (condition);
>
> > which did exactly what I always expected it to do: Execute the list of
> > statements, *then* check for the condition, and if it didn't hold true, repeat
> > the whole smash over and over again.
>
>   The problem with that is that it will execute the body always at least
> once. If it should never be executed (which isn't even a rare occurrence),
> you will need to add a conditional around the entire repeat-until loop,
> and the condition will be a duplicate of the 'until' condition.

I didn't claim that to be the ideal loop. I just said it was the most intuitive
in my eyes.

Post a reply to this message

"Kenneth" <kdw### [at] earthlinknet> wrote:
> (I'm not sure why the SDL learning-curve didn't put ME off when I started with
> POV-Ray--probably because the astounding visual results of the program just
> outweighed any seeming syntax difficulties. I just *had* to learn it!

Maybe that's because with POV-Ray, you have always something more you *can*
learn, but not much that you *must* learn. Any you always have plenty of ways
to do things. For example, you can choose whether you prefer to invest lots of
time coding routine stuff, or hack up an awfully complex macro to do it for
you. It's all up to whoever is in charge of the keyboard.

Post a reply to this message

clipka escreveu:
> Warp <war### [at] tagpovrayorg> wrote:
>> clipka <nomail@nomail> wrote:
>>> Just for starters: The main difference would probably be a significant increase
>>> in the number of semicolons used.
>>   I'm not liking the sound of that. I really like being able to eg. create
>> lists of elements in a loop without having to worry about the commas.
>> If you make the current SDL "more formalized" and "consistent", you will
>> be removing a lot of its current flexibility which makes it so great.
> 
> Warp, please make up your mind: Do you want a *scripting* language, or a
> *preprocessing* language?
> 
> In a preprocessing language, you indeed have to worry about the commata because
> you're generating *source* code that will be parsed again.

If povray was to use Scheme as scripting language, there would be no 
such worries:
'(1 2 3 4 5 6 7 8)

Or:
(define vec (make-vector 10))
((range 0 9) '() (lambda (i o) (vector-set! v i (* i i)) o))

v => #(0 1 4 9 16 25 36 49 64 81)

After all, Lisp syntax is very uniform.  Besides, there are quite a few 
good and small Scheme open-source interpreters out there geared for 
scripting.

Of course, while there would be no semicolons, there'd be lots of 
parentheses. ;)

and here ends Scheme advocacy.  Your turn, Andrew.

-- 
a game sig: http://tinyurl.com/d3rxz9

Post a reply to this message

clipka <nomail@nomail> wrote:
> Warp, please make up your mind: Do you want a *scripting* language, or a
> *preprocessing* language?

  I want the current SDL to remain as flexible as it is now. There's no
need to make it more rigid just for the sake of it being "easier for
a converter to parse".

  Scripting languages should make the life of the users easier, not the
other way around.

> In a preprocessing language, you indeed have to worry about the commata because
> you're generating *source* code that will be parsed again.

> In a scripting language, you just loop and add elements to some data container.

  The current SDL has no data containers (except for the very rigid array),
and everything is created as SDL source. Thus it should remain as a
preprocessing language in order to make this task easier.

  The new scripting language can use a completely different approach.

> I thought you were so much in for render-time scripting with some VM; how on
> earth are you going to do that with a preprocessing language??

  I never wanted a render-time scripting VM for the *current* SDL. That's
just impossible.

-- 
                                                          - Warp

Post a reply to this message

nemesis <nam### [at] gmailcom> wrote:
> If povray was to use Scheme as scripting language, there would be no
> such worries:
> '(1 2 3 4 5 6 7 8)
>
> Or:
> (define vec (make-vector 10))
> ((range 0 9) '() (lambda (i o) (vector-set! v i (* i i)) o))
>
> v => #(0 1 4 9 16 25 36 49 64 81)

Yuck! No way am I gonna support *that* approach >_<

Not that I'd say Scheme or Lisp would suck, but... well, I don't have the
slightest clue how to *decipher* it - could be ROT13-encrypted ancient egypt,
from all I see :P

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
>   I want the current SDL to remain as flexible as it is now. There's no
> need to make it more rigid just for the sake of it being "easier for
> a converter to parse".
>
>   Scripting languages should make the life of the users easier, not the
> other way around.

Yes, and that's *exactly* why a scripting language should be consistent in its
own grammar.

Now tell me, why are the arguments to #write and #read in parentheses (including
the file descriptor), while those of #fopen and #fclose are not?

Why does #debug take a single string, while #write takes an arbitrary mix of
strings, floats or vectors?

Why is the comma between the value and the co-ordinate of a cubic spline point
mandatory, while that between the co-ordinate and the next point isn't?

Why is a semicolon after a #define and #version statement required, but nowhere
else?

Just a few examples.

>   The current SDL has no data containers (except for the very rigid array),
> and everything is created as SDL source. Thus it should remain as a
> preprocessing language in order to make this task easier.

Maybe we have a misunderstanding here. When I mentioned my proposal would mainly
add a lot of semicolons, I was talking about existing features. It would provide
quite a few more.

>   The new scripting language can use a completely different approach.
>
> > I thought you were so much in for render-time scripting with some VM; how on
> > earth are you going to do that with a preprocessing language??
>
>   I never wanted a render-time scripting VM for the *current* SDL. That's
> just impossible.

It is impossible indeed for code relying on the preprocessor nature of the SDL.
But I consider it reasonable to deprecate such code.

Note that I'm not talking about the *current* SDL. I'm talking about a *new* SDL
that will - to the extent that macros are "well-behaved" - have a strong
syntactical resemblance to the current one.

Post a reply to this message

clipka wrote:
> Not that I'd say Scheme or Lisp would suck, but... well, I don't have the
> slightest clue how to *decipher* it - could be ROT13-encrypted ancient egypt,
> from all I see :P

Errata: read v as vec. :P

 >> (define vec (make-vector 10))

This is clear enough, I guess:  defines vec to be the result of 
(make-vector 10), which should be self-evident as well:  makes a vector 
(array) of 10 elements.

 >> ((range 0 9) '() (lambda (i o) (vector-set! vec i (* i i)) o))

This is not plain Scheme, it's an idiom I use.  Let's decompose it.

First: in Lisp, anything in the head of a list (everything between 
parentheses) should be a function or a macro, should the list be 
evaluated.  An unevaluated list is like '(1 23 "foo") etc.  It's said to 
be quoted.

For instance:
(+ 1 2 3) results in the application arguments 1,2,3 to function +, thus 
yielding 6

'(+ 1 2 3) results in the list with the symbol + and numbers 1,2,3.

So from now on it's obvious that (range 0 9) results in a function, 
otherwise it wouldn't be in the head.

range is a handy function that returns, guess what!, another function. 
The function returned is an *iterator* for the given "range", in this 
case, 0 to 9.

The *iterator function* so returned gets 2 parameters:  the /initial 
value/ to be used as first result and a /reducer function/ that takes 
the current iteration step and the current result and returns a new result.

So, '() is the /initial value/ and (lambda (i o) (vector-set! vec i (* i 
i)) o) is the /reducer function/ I provided.  Both are fed to the 
*iterator function* returned by (range 0 9) which will successively feed 
the /reducer/ the current iteration item and the result so far.

In other words:  range returns a "functional" for loop. :) (I don't like 
Scheme's standard loop mechanism, "do")

(lambda args body ...) is Scheme's way of creating an anonymous 
function.  I could as well just previously defined it and given the name 
to the iterator, say:

(define powerize (lambda (i o) (vector-set! vec i (* i i)) o))
or sugared:
(define (powerize i o) (vector-set! vec i (* i i)) o)

and then:
((range 0 9) '() powerize)

anyway, (vector-set! vec i (* i i)) sets vector vec element i (vec[i] in 
C) to be (* i i).  And what is i?  i is the first argument to the 
/reducer function/, which represents the current iteration item, in this 
case a number in the 0-9 range.

Summing up:  given i = from range 0 to 9, it will set the current vector 
element to i*i.

Let's put c and my scheme idiom side-by-side:

((range 0 9) '() (lambda (i o) (vector-set! vec i (* i i)) o))
for(int i=0;i++<10;)vec[i]=i*i;

whoa!  Just remember it's all but a user-defined function with no 
syntatic sugar provided by macros wrapping it up.  I could just as well 
provide one such sugared version:

(define-syntax for
     (syntax-rules (=>)
       ((for i from to => body ...)
        ((range from to) #t (lambda (i o) (begin body ...) o)))))

(for i 0 9 => (@! vec i (* i i)))
for(int i=0;i++<10;)vec[i]=i*i;

Much better. :)
@! is my personal alias for vector-set!

Also, not seen here is the hability to actually have some useful result. 
  I mean, setting elements of an array is pretty much an imperative 
operation, but still you could simply pass the result of the whole call 
to yet another function using the vector just set, simply by doing:

((range 0 9) vec (lambda (i o) (vector-set! vec i (* i i)) o))

and then, using it like:
(vector-ref ((range 0 9) vec (lambda (i o) (vector-set! vec i (* i i)) 
o)) 2) => 4

Something you can't do with the built-in C for loop.


Was it really that hard? :)

BTW, aside from not mentioning it is a lexically-scoped language, you've 
just learned pretty much all the basic semantic of Scheme.  It is that 
simple a language.  Even though my particular idiom may sound a little 
daunting at first... :P

Post a reply to this message