Community

Somewhere there is the dream of a pure function call syntax
abs(real) sqrt(abs(real) x);
Total unification. And possibly total impossibility.
Looks beautiful tho.
- Bent
"Steven Schveighoffer" <schveiguy@yahoo.com> skrev i meddelelsen
news:gc9ab4$1ai4$1@digitalmars.com...
> "Andrei Alexandrescu" wrote
>> (Background: Walter has kindly allowed ".()" as an alternative to the
>> ugly "!()" for template argument specifications.)
>
> :(
>
> Another case of multiple syntax possibilities. What was wrong with !() ?
> I didn't consider it ugly at all. In fact, I prefer it.
>
> It's very alarming to me that something like this just has no problem
> getting in the language without community feedback.
>
>> Just a quick question - I am feeling an increasing desire to add a
>> template called Positive to std.typecons. Then Positive.(real) would
>> restrict its values to only positive real numbers etc.
>
> I wouldn't use it, if that helps at all. Even if it was in Tango (i.e.
> not just because I don't use Phobos).
>
> -Steve
>

Bent Rasmussen wrote:
> Somewhere there is the dream of a pure function call syntax
>
> abs(real) sqrt(abs(real) x);
>
> Total unification. And possibly total impossibility.
>
> Looks beautiful tho.
>
> - Bent
>
But how to check 0 ∉ gamma(ℝ)?
This notation is simple for invertible functions and sets with finite
elements, but won't be applicable for more complicated functions and types.
> "Steven Schveighoffer" <schveiguy@yahoo.com> skrev i meddelelsen
> news:gc9ab4$1ai4$1@digitalmars.com...
>> "Andrei Alexandrescu" wrote
>>> (Background: Walter has kindly allowed ".()" as an alternative to the
>>> ugly "!()" for template argument specifications.)
>>
>> :(
>>
>> Another case of multiple syntax possibilities. What was wrong with
>> !() ? I didn't consider it ugly at all. In fact, I prefer it.
>>
>> It's very alarming to me that something like this just has no problem
>> getting in the language without community feedback.
>>
>>> Just a quick question - I am feeling an increasing desire to add a
>>> template called Positive to std.typecons. Then Positive.(real) would
>>> restrict its values to only positive real numbers etc.
>>
>> I wouldn't use it, if that helps at all. Even if it was in Tango
>> (i.e. not just because I don't use Phobos).
>>
>> -Steve
>>

On Sun, 05 Oct 2008 17:49:48 +0400, Andrei Alexandrescu
<SeeWebsiteForEmail@erdani.org> wrote:
> KennyTM~ wrote:
>> Michel Fortin wrote:
>>> On 2008-10-05 01:14:17 -0400, Andrei Alexandrescu
>>> <SeeWebsiteForEmail@erdani.org> said:
>>>
>>>> I don't favor "." any more than the next guy, but I am glad there is
>>>> awareness of how unfit a choice "!" is. If you have any ideas, please
>>>> post them! Ah! I! Exclaimed! Again!
>>>
>>> Hum, I don't think we have much choice, it'll have to be something in
>>> this lot:
>>>
>>> Positive!(real)(joke);
>>> Positive.(real)(joke);
>>> Positive#(real)(joke);
>>> Positive@(real)(joke);
>>> Positive&(real)(joke);
>>> Positive`(real)(joke);
>>> Positive´(real)(joke);
>>> Positive^(real)(joke);
>>> Positive¨(real)(joke);
>>> Positive\(real)(joke);
>>>
>>> Anything else I forgot?
>>>
>>> Or we could use special delimiter characters:
>>>
>>> Positive<real>(joke);
>>> Positive“real”(joke);
>>> Positive«real»(joke);
>>> Positive#real@(joke);
>>>
>>> Each having its own problem though.
>>>
>>> My preference still goes to "!(".
>>>
>>> - - -
>>>
>>> The ".(" syntax makes me think more of something like this:
>>>
>>> void func(T, alias methodOfT, A...)(T obj, A args)
>>> {
>>> obj.(methodOfT)(args);
>>> }
>>>
>>> which I which I could do. If methodOfT was a string, I suppose I could
>>> use string mixins, but it pushes diagnostics about misnamed methods
>>> further in the template and requires adding quotes to the template
>>> parameter when instanciating.
>>>
>> Argh, actually I once have a strong desire making
>> f«T»(x);
>> a valid construct, and to workaround that « and » can't be easily
>> typed you could substitute it with
>> f\<T\>(x);
>> ---
>
> Yah I would've like French quotes too.
>
>> Anyway, I think the .() syntax is not as good as !() because the . is
>> pretty hideous before another punctuation mark (which may be a good
>> thing, I don't know), and one could easily miss it.
>> And even if .() is allowed, please don't remove !() -- it will break
>> significantly many code, and it doesn't cause any ambiguity either
>> (unlike .func() vs .prop).
>
> Many languages have successfully dealt with similar situations by simply
> allowing both but promoting only one in books and other documentation.
> Speaking of which, I'm on verge of signing with Addison Wesley Longman
> for delivering TDPL in April.
>
>
> Andrei
Great news! Your site still says it appears in October, though.

Andrei Alexandrescu wrote:
> Steven Schveighoffer wrote:
>> If this change is implemented, Walter is going to have a hard time
>> arguing that it's not worth changing invariant to immutable...
>
> Speaking of which... guess what he just did :o).
*dances for joy*
Sean

Andrei Alexandrescu wrote:
> Sean Kelly wrote:
>>
>> Will do. It's easy enough to search-replace '!' with '.'
>
> You'll need a sed expression to not catch unary ! and != as well.
Nah, just replace "!(" with ".(" I basically never use "!(exp)" in
conditions so there should be no problems.
Sean

Sean Kelly wrote:
> Andrei Alexandrescu wrote:
>> Steven Schveighoffer wrote:
>>> If this change is implemented, Walter is going to have a hard time
>>> arguing that it's not worth changing invariant to immutable...
>>
>> Speaking of which... guess what he just did :o).
>
> *dances for joy*
Well are you greased properly for giving .() a shot? :o)
Andrei

Sean Kelly wrote:
> Andrei Alexandrescu wrote:
>> Sean Kelly wrote:
>>>
>>> Will do. It's easy enough to search-replace '!' with '.'
>>
>> You'll need a sed expression to not catch unary ! and != as well.
>
> Nah, just replace "!(" with ".(" I basically never use "!(exp)" in
> conditions so there should be no problems.
Well well laziness never helps.
sed --in-place -e 's/\([a-zA-Z0-9_]\)\(\s*\)!\(\s*\)(/\1\2.\3(/' *.d
Preserves whitespace used around !, too. The major problem is it will
transform insides of strings too. Also, won't transform instantiations
across lines, and won't work with Unicode symbols...
Andrei

KennyTM~ wrote:
> Michel Fortin wrote:
>> On 2008-10-05 01:14:17 -0400, Andrei Alexandrescu
>> <SeeWebsiteForEmail@erdani.org> said:
>>
>>> I don't favor "." any more than the next guy, but I am glad there is
>>> awareness of how unfit a choice "!" is. If you have any ideas, please
>>> post them! Ah! I! Exclaimed! Again!
>>
>> Hum, I don't think we have much choice, it'll have to be something in
>> this lot:
>>
>> Positive!(real)(joke);
>> Positive.(real)(joke);
>> Positive#(real)(joke);
>> Positive@(real)(joke);
>> Positive&(real)(joke);
>> Positive`(real)(joke);
>> Positive´(real)(joke);
>> Positive^(real)(joke);
>> Positive¨(real)(joke);
>> Positive\(real)(joke);
>>
>> Anything else I forgot?
>>
>> Or we could use special delimiter characters:
>>
>> Positive<real>(joke);
>> Positive“real”(joke);
>> Positive«real»(joke);
>> Positive#real@(joke);
>>
>> Each having its own problem though.
>>
>> My preference still goes to "!(".
>>
>> - - -
>>
>> The ".(" syntax makes me think more of something like this:
>>
>> void func(T, alias methodOfT, A...)(T obj, A args)
>> {
>> obj.(methodOfT)(args);
>> }
>>
>> which I which I could do. If methodOfT was a string, I suppose I could
>> use string mixins, but it pushes diagnostics about misnamed methods
>> further in the template and requires adding quotes to the template
>> parameter when instanciating.
>>
>
> Argh, actually I once have a strong desire making
>
> f«T»(x);
>
> a valid construct, and to workaround that « and » can't be easily typed
> you could substitute it with
>
> f\<T\>(x);
Yes. Trigraphs were such a good idea in C, let's bring them to D X_X
- Gregor Richards