Lukas Winter <web### [at] geloeschtremovethisandthedotbeforenet> wrote:
> Or even:
> MySphereProducingFunction = function(named pos)
> { sphere { midpoint = pos; /*...*/ } };
>
> Any object applied to a function block would be its return value.

Yes, that makes a lot of sense.

> Yes, from the syntactical point of view "func(/*...*/)" and "func" have
> different types in most languages. I don't like this, because what type
> has func(some_parameter /*but not the other*/) then? In most languages
> you have to specify all arguments or none... Seems to be a personal
> dislike, though ;)

I think functions should be just functions, and some rule would have to be
established how to handle missing or surplus parameters. Easiest would be to
discard surplus ones, and have missing ones set to "undefined".

> > I'd say that the parameter naming / ordering thing is rather independent
> > of objects vs. functions: It's just a common convention of most
> > programming languages that function parameters are passed by position
> > instead of by name.
> >
> Right. Perl has named parameters but how they work seems rather obscure
> to me. Just what you'd expect from Perl ;)

I'd expect some specific prefix symbol reserved for them :P

> >> If we add input properties which delay calculation of other properties
> >> to our language then functions and prototypes can perform the same task
> >> with a different syntax. I'm not to happy with that, _one_ way to do
> >> things should be enough.
> >
> > I agree with that. But I guess the concept of individual properties
> > delaying the calculation of a whole entity would be hard to grasp for
> > the average user, or even for the average programmer (it is for me, at
> > any rate ;)).
> >
> It's just the other way round: The program doesn't follow a sequence of
> instructions but has a number of goals it has to achieve. Each time a
> resource needed to achieve the current goal is missing, the program goes
> to the next. Hopefully the resource will become available later, perhaps
> as the result of another calculation.

Either way it messes with the imperative paradigm most mainstream languages
still follow today - if not on large scale, then at "molecular" level (e.g.
individual functions/methods/whathaveyou): "Do this; next do that; next do foo;
next do bar; ..."

Unless of course it's done in a totally transparent way. But then again I'd not
consider that a language trait, but some particular implementation's way of
optimizing things.


> > Hm... there is something to this indeed.
> >
> > However, some things need to be clarified:
> >
> > Using bare expressions within a curly brace doesn't strictly create a
> > copy, but modifies the copy of the prototype. Would the tilde operator
> > force creation of a new copy?
> >
> > In that case, it would be equivalent to:
> >
> > MyTransformedSphere = MySphere { MyTransform };
> >
> > which is just about as easy to type. It would also then raise the
> > question whether the following would be possible, too:
> >
> > MyColoredSphere = MySphere ~ color: #<1,0,0>;
> >
> > In that sense, the tilde operator would actually be the single-statement
> > equivalent for curly braces (which would happen to nicely fit with the
> > shapes of the symbols :))
> >
>
> Supplying your own rules for applying a object to some other object would
> just be an act of overloading the ~ operator. Something like
>
> PaintInHappyColors = basic {}; //clone the most fundamental prototype

I'm not sure how that answers my question. I think we're getting a bit fuzzy
here.


> > Or, think of debugging a large formula. With this "on-the-fly
> > assignment", it is a piece of cake; no need stripping it down to
> > individual terms (and risking to break it again as soon as you
> > re-assemble it because you don't want 20 lines of assignments where a
> > two-liner would do).
> >
>
> The C way to do that:

Please not! Because, as you say yourself:

> Easy, because = returns the assigned variable. That does definitely
> confuse a non-programmer who doesn't know the difference between = and ==.

It would also raise a conceptual problem, becuase then

  MySphere = sphere { ... };

would not only be an assignment, but *also* an expression - which would evaluate
to a sphere instead. If we want "bare" expressions to be read as "attach this to
the current object", the logical consequence would be that this assignment would
*also* attach the sphere to the scene.

I don't think that is what we want.


So we do need different syntax for assigment statements and "on-the-fly
assignments".


> > Think of this syntax I had pondered:
> >
> > sphere {
> >   .center = <0,0,0>;
> >   .radius = 1;
> >   temp = rand();
> >   texture {
> >     test = temp + 1;
> >     .answer = 42;
> >   }
> >   .foo = bar;
> > }
> >
> > I think this syntax would make it perfectly plain to most developers
> > accustomed to the "foo.bar" field/member notation that .center is a
> > property of the sphere, while for instance temp is not, and texture is
> > defined in some other scope as well.
> >
> Would it? I never write "this->member" in C++, just member. Some people
> prefix their members with "m_", I don't. It's a matter of personal
> taste...
>
> > Alas, it really "uglifies" the indentation!
> >
> Every reference to a variable outside the current scope necessarily does
> this, if I understand you correctly.

I don't think you got my point.

My basic point was: Syntax should not only be concise and consistent, but also
pretty as well.

My example was the above, which was indeed a syntax I pondered a while to
distinguish members from variables, by simply prepending a dot before member
names, to allude to the "myInstance.myMember" notation common in mainstream OO
languages - making the empty name shorthand for "this", so to speak.

My argument was that in this particular syntax, the many leading dots on a line
would tend to visually "distort" the indentation, and that this would make the
code ugly.

So with an example for an ugly syntax, my conclusion was that I want the new
POV-SDL syntax to be pretty, and my appeal was to take beauty into
consideration besides conciseness, consistency and other traits.


> > And in a language such as this, I think there should be a clear
> > distinction between the "modification blocks" - which open up a new
> > context for "applying" things to - and control blocks.
> >
> Another matter of taste, I suppose. It's just that when I want my code to
> be verbose, then _I_ want to introduce the verbosity, not the designer of
> the programming language I happen to code in.

How would you do that as a user in a language that - as an extreme example -
would go

  @ i [1,10] {
    ? i < 5 {
      <<i
    } | {
      <<"many"
    }
  }

instead of

  for i in 1 to 10 do
    if i < 5 then
      print i
    else
      print "many"
    end
  end

Fact is that every language carries its own inherent level of verbosity, which
you as a user typically cannot really influence much.


> Of course cameras and basic modifiers should be included by default.
> Namespaceing on the other hand is just too much typing for a lazy person
> like me :P

Agree; something like

  pov:sphere { ... }

wouldn't really go well.

But how about

  include "sphere" as pov;
  include "box";

in case you *do* want a namespace - which could give you

  pov.sphere { ... }

or straigtforward

  box { ... }

"al gusto".


> There should really be opinion polls among POV-Ray users to decide on
> prettyness ;)

Maybe. But I think everything is an improvement over the current "#while...#end"
anyway :P

Post a reply to this message