Am Thu, 16 Apr 2009 08:31:31 -0400 schrieb clipka:
> 
> 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".
> 
Please don't do that, hunting down bugs caused by uninitialized or 
undefined values can be tedious. In my opinion just signaling an error is 
better.
In my own perfect little language, functions with incomplete argument 
list would return functions that take the missing parameters. Return 
values would be written to properties of the function.

>> 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
> 
No, in fact I think it's an extra hash as a parameter.

>> >> 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; ..."
> 
As long as you disallow side-effects like output or time dependent 
values, not at all. Then it's just "Do this; oh, you can't do that, you 
have to do that first; to do that, you have to do foo;  now you can do 
this; next do bar; ..." Of course if you do allow output as side effects 
then it would be all messed up.

> 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.
> 
Actually, I'm tired of implementing lazy evaluation in strictly evaluated 
frameworks...
> 
>> > 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?
>> >

Sorry I didn't answer that. If I think about it, no, but I'm not sure... 

> [...]
> 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.
> 
Haven't thought about that, you're right. Then, perhaps we do want "as" 
after all. But it still seems to me like a duplicate of "=" where the lhs 
and rhs are swapped ;)

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


>> 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.
> 

I see the dots as reminders, that a variable resides in the current 
scope, and think it's good that they stand out a bit. Maybe we'll want 
properties and other variables to be clearly distinguished by such 
prefixes, then again I think the approach "everything is a property" is 
very elegant.
I still believe that if no prefix is specified, the variable/property to 
be accessed should be the most local one that's defined.

> 
>> > 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"
>     }
>   }
> 

If this language allows me to define a construction that does the same as 
@ or ?, then it's fine. Maybe with

#for([int] list, #func(int)) = {@ i list { func(i) }}

for([1,10], #(i) {
  ? i < 5 {
     <<i
    } | {
      <<"many"
    }
  })

Then the langauge is powerful enough for me to create my own verbosity. I 
must admit that nobody would want to do things like that all the time, 
but then again this fictional language is an extreme example.

> 
>> 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
> [...]
> 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".
> 
Just as long nobody forces me to use namespaces, that's fine by me.
> 
>> 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

right... no wait, that's a reserved word *g*

Post a reply to this message