|
|
Re: Postfix Typecast Operations
|
Posted: Sep 29, 2005 6:40 AM
|
|
> > First off, I will start by saying that, in my opinion,
> the
> > reason why your example does not feel right is that
> your
> > casting is done the same way you would use a function.
> > Functions use verbs, so our brains make verbs out of
> them:
> > "centimeter the fun minus that", as opposed to your
> > prefered "the fun minus that centimeters". Which I'll
> > admit does sound nicer, but is it warrented?
>
> This is pointless because the example is completely
> artificial. You cannot reasonably argue the merits of
> syntax based on a single example. I was simply countering
> the previous argument.
Yes, I was just counter-countering myself. If the example wasn't there, I would have come up with my own. Feel free to give an example that truly shows the advantage of postfix typecasting at it's fullest.
> > Whenever I see anyone play with the ordering of the
> > syntax, it always raises an internal flag
>
> Compared to what? A particular individual's narrow view of
> what syntax should be? There is no prescribed correct
> syntax from which to measure. Historically successful
> programming language syntax is that which maps to the
> non-programmers conventions, such as those already
> established for centuries by mathematicians, scientists
> and engineers.
You're right, I should have made myself clearer: what irked me was that there were two methods to do the exact same thing. I don't mind if you have something like a + b being represented as well as a._plus(b), or what have you, since it is highly unlikely the _plus will be used for anything else, but I think postfix is a precious syntax rule, and it could be used for something that isn't already implemented some other way.
> > ... First of all,
> > let's go with a more traditional, less ambiguous way
> of
> > prefixing a cast:
>
> Traditional from what sense?
If you don't like traditional, let's stick with less ambiguous. All that I meant is (though I admit "traditional" was the wrong word to express this) I know we both know this way of casting. The exact syntax is not the issue here, as long as it is different from the syntax for something else (in this case, calling a function).
> > do_it((cm)(fun() - that()) / (sec)(something() *
> > the_other())
>
> How is it less ambiguous?
Because cm(...) could be read as a function. It is only after your brain reads it that you realize it is a cast, because it isn't a verb. (cm)(...) on the other hand makes it clear that it is a cast probably before your brain even interprets the meaning of the word inside it, cm. Knowing what something is doing before reading the english that describes it increases the speed of human reading interpretation immensely. I am not saying (x)(...) is the right or only way to cast. It is just, in my opinion, better because it gives context far better than a syntax rule shared with functions.
> > This personally feels just as good as with using a
> suffix
> > (of course, this line of code itself in real code
> should
> > maybe be broken up into parts).
> >
> > But if trying to map your
> > language to English is your concern, tell me how you
> > would, for example, make a function that checks if a
> > number divides another?
>
> This has nothing to do with postfix typecast operations.
Well if matching English, or math, or some other non-programming syntax isn't your concern, then what about postfixing gives you a warm feeling inside that tells you it is right?
> > divides(a, b)? In a stream of
> > code, this looks weird, because the verb tense is
> > different than all the other function verbs. Of course,
> in
> > normal math, you would do "a divides b", but again that
> is
> > playing with the ordering of your language. Would it be
> > worth it in this case too?
>
> No. Some language do support this though (e.g. Scala).
> This is however entirely unrelated. My goal wasn't to
> model english but rather to model physical equations.
Well again, a divides b (which, if the pipe character weren't already reserved in Heron, I could have written as a | b, but the point is that it is something that isn't implemented natively in the language, so let's forget about the pipe) is how it would be represented in physical equations, no?
> > I just think that using suffixes can probably be used
> for
> > something better in the future than just another way of
> > doing casting. We already have one of those.
>
> What do you mean "we already have one of those"?
We already have, in Heron, a method of casting is what I meant. Prefix casting. Unless you're saying you want to get rid of prefix casting, but I wasn't under that impression at all. That would invalidate my whole rebuttle. :)
> Yes. This can be defined as needed on the fly using
> template metaprogramming. Take a look at
> http://www.boost.org/libs/mpl/doc/tutorial/representing-dimensions.html.
Thanks for the link-up.
|
|
Previous Topic
