[nem-en] Syntax change - your thoughts?

[Kamil Skalski]

>
> I get the impression that the decision to use a dot before the type
> parameters in an expression context was driven by an implementation decision
> – without the dot, the expression would look like an indexer call (and
> indeed, neglecting the dot results in such an error message).
>

Did you take a look at http://nemerle.org/Generic_specifier ?
And especially http://nemerle.org/Generic_specifier#Why_not_.5B.5D.3F

There is one, though not very common reason, why plain [] causes problems.
If it wouldn't collide with the rest of the language I would also like
to use alwas [].

And the main reason why we generally ignore this consistency is that
in real programs there is rarely any need to use .[] syntax. You can
write 5000 lines of code using generics havily without even knowing
it.
You just write
def x = List();
x.Add (1);
1 + x[0];




>
>
> My point is that the syntax should be consistent and the compiler should
> have to work a little harder – I should be able to write:-
>
>
>
>         def x = AGenericClass[int]();
>
>
>
> as well as
>
>
>
>         AGenericClass[string].ackleWithIt[int](2);
>
>
>
> and the compiler should know that 'AGenericClass' is the leading part of a
> generic type, not the name of a variable that is about to be subject to an
> indexing operator call!
>
>
>
>
>
> Well, you might say I'm dwelling on trivial details here – but I keep
> tripping up over this syntax inconsistency and find myself either trying
> alternatives to get the compiler to vet my syntax, or going to the Nemerle
> homepage to check the language grammar.
>
>
>
> This isn't right – a good programming language is something that working
> programmers should be able to internalise – the syntax should be intuitive.
>
>
>
> Consider that C++, Java and C# all have the consistent syntax approach in
> their use of generics / templates: the expression usages mirror the
> definition syntax. I would argue that if the goal is to attract a base of
> software engineers to rally in support of the language (and I would
> certainly like to see this happen, as I know others on this mailing list
> would), then perhaps this change of the language syntax should be included
> in order not to put off folk who are used to the consistent syntax in their
> 'home' languages.
>
>
>
> It's all very well to have good features in a language – and I think Nemerle
> is packed full of them, put together in an elegant way – but don't forget
> the mundane ergonomics factors. People have to sit down in front of a
> computer and type this stuff in, day after day after day!
>
>
>
> In case you aren't convinced, ask yourselves how many Lisp, Algol 68 and APL
> programmers you've met in your careers. Why is Java becoming increasingly
> popular in comparison with C++? It isn't increased expressive power; it's
> convenience of everyday use that swings these matters.
>
>
>
>
>
> OK, that's the polemic over with – meanwhile there are the language
> developers and the existing user community to consider. So what are your
> thoughts on this?
>
>
>
> Is my difficulty with the syntax just a case of my brain being addled with
> age? ;-)
>
>
>
> Perhaps there is a more fundamental reason that I'm not aware of that
> prohibits using semantic context to disambiguate the parsing?
>
>
>
>
>
>
>
> In closing – I'd be delighted to investigate making the changes myself to
> the compiler to support a consistent generics syntax, if others become
> convinced that it should change. I suspect that the Wroclaw team might be
> able to carry these out a bit faster then me, though. J
>
>
>
> One last thing – I'm on holiday for the next four days, so if anyone directs
> a question at me, please don't be offended if I don't reply immediately –
> I'll try to peek at the mailing list if I can, though.
>
>
>
>
>
> Kind Regards,
>
>
>
> Gerard Murphy www.sageserpent.com
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> https://nemerle.org/mailman/listinfo/devel-en
>
>
>


--
Kamil Skalski
http://nazgul.omega.pl