Parameterized Keywords

[Idan Arye via Digitalmars-d]

On Monday, 7 March 2016 at 05:56:54 UTC, Patience wrote:
> Just curious if anyone can see the use for them?
>
> e.g., for[32], switch[alpha] //alpha is a user type, if[x](x < 
> 32)
> etc..
>
> The idea is two-fold, one is to allow polymorphic keyword 
> behavior(it's behavior depends on the argument) and to allow 
> the code itself to manipulate the behavior.
>
> Of course, the behavior isn't easily define for the above 
> examples. So far all I can think of is various simple 
> modifications:
>
> foreach[?] <- executes only if there are one or more iterations 
> and checks for nullity. This allow one to avoid writing the if 
> check.
>
> int[size] <- creates an integer of size bits.
>
> etc...
>
> I can't see much benefit but maybe someone has some good uses?
>
> These could be thought of as "attributes for keywords". The 
> programmer would have to define precisely what if[x] means.
>
> Obviously the biggest objection is "It will obfuscate 
> keywords"... Please don't obfuscate the question with such 
> responses.

This... looks like you have a solution and now you are looking 
for a problem. I fail to see the need to parameterize the 
*keywords*, when what you really want to modify is the 
*constructs* created from these keywords. That is, you don't want 
to modify `if` keyword - you want to modify the whole `if` 
statement(`if (a) { b(); } else { c(); }`). Modifying the keyword 
is just a means to that end.

This distinction is important because the term "keywords", while 
distinctive and important at the lexical phase, is too broad at 
the grammar phase and is no longer meaningful once we reach the 
semantics phase. Parameterizing `int` is different from 
parameterizing `foreach` is different from parameterizing `pure`.

Of course, this statement doesn't hold for homoiconic languages, 
where keywords are actual values and parameterizing them simply 
means returning a different value. Also, I'm assuming you mean to 
allow defining parameterizations at library level - otherwise 
they won't be very useful, since you could simply create new 
syntactic constructs.

So, assuming you the language is not homoiconic and that users 
and library authors should be able to define("overload") their 
own keyword parameterizations, the keywords will need to be 
partitioned into several categories: data-types, annotations, 
statements etc. Each category should have it's own 
parameterization overloading rules - so `int[...]` and 
`float[...]` will have similar rules, which will be very 
different from `if[...]`'s rules.

Now, let's focus, for a moment, on types - because 
"parameterizing" types is a solved problem - it's called 
"templating". You usually want parameterized types to also be 
types - your `int[12]` should be a type, usable wherever types 
are usable - which is exactly what templated types do - it's easy 
to implement `CustomSizedInt!12` which does exactly what your 
`int[12]` does. In fact, templated types are better, because:

  1) When you encounter `CustomSizedInt!12` and want to know what 
it does, you need to search for `CustomSizedInt`'s declaration - 
an extremely common problem, automated by many simple-to-use IDE 
features and command line tools. To divine `int[12]`'s meaning 
you'd have to look for the implementation of a the 
parameterization of `int` with another `int`(or with a `long`, or 
with a `uint`, or with a...), and you need a more complex query 
to search for it.

  2) `int[12]` is a user defined type, but it's conceptually 
coupled to `int`. The mere concept of parametrized keyword types 
is coupled to primitive types. Templated types do not have this 
limitation - they can depend on whatever they want to - so you 
have much more freedom. Even if parameterized keywords could do 
everything templated types could, you'd have to abuse 
them(resulting in many code smells) whenever you want a type 
doesn't strictly resolve around a primitive type - something that 
comes naturally with templated types.

  3) Code that invokes user-defined behavior should have an 
"anchor" - something the definition of that behavior resolves 
around. When you call a function it's the function. When you call 
a method it's the object's type. When you use an overloaded 
operator it's the type of one of the operands. When you use 
`int[12]`? Both `int` and `12` are built in - there is no anchor. 
If `int[12]` is to be library defined, it would have to be more 
like `int[SizeInBits(12)]`(so `SizeInBits` is the anchor), and 
suddenly it doesn't look that syntactically appealing compared to 
`CustomSizedInt!12`...


So, that was for keywords that represent types - what about other 
keywords? I picked types because it's something D(and many other 
languages) already have, but I claim that the same reasons apply 
to all other keywords. Let's look at another easy one - 
annotations. Let's say you want to paramererize `pure` - e.g. 
`pure[MyPureModifier]` - so it'll do something a bit different. 
It'll still be an annotation, so it'll have to annotate some 
declaration. If you are already going to implement custom 
modification of declarations, why not give that power to UDAs? 
`@MyPure` looks better, has a clear anchor, it's definition is 
easier to search, and it doesn't have to be related to an 
existing modifier with and existing purpose.


What about more complex stuff, like your `foreach[?]`? Many would 
suggest macros, but even without going to hyperblown macroland, 
identifiers are better than parameterized keywords. Ruby has a 
nice syntax for it with blocks. Instead of parameterizing the 
existing `for` into `for[?]`, it lets me define my own "keyword" 
- `foreach?`:



[1] pry(main)> for x in [1, 2, 3]
[1] pry(main)*   puts "Loop1: #{x}"
[1] pry(main)* end
Loop1: 1
Loop1: 2
Loop1: 3
=> [1, 2, 3]
[2] pry(main)> for x in nil:
SyntaxError: unexpected ':', expecting keyword_do_cond or ';' or 
'\n'
[2] pry(main)> for x in nil
[2] pry(main)*   puts "Loop2: #{x}"
[2] pry(main)* end
NoMethodError: undefined method `each' for nil:NilClass
from (pry):4:in `__pry__'
[3] pry(main)> def foreach?(collection)
[3] pry(main)*   if collection
[3] pry(main)*     for entry in collection
[3] pry(main)*       yield entry
[3] pry(main)*     end
[3] pry(main)*   end
[3] pry(main)* end
=> :foreach?
[4] pry(main)> foreach? [1, 2, 3] do|x|
[4] pry(main)*   puts "Loop 3: #{x}"
[4] pry(main)* end
Loop 3: 1
Loop 3: 2
Loop 3: 3
=> [1, 2, 3]
[5] pry(main)> foreach? nil do|x|
[5] pry(main)*   puts "Loop 4: #{x}"
[5] pry(main)* end
=> nil



The main idea in all these examples is the same - instead of 
parameterizing the existing keywords and syntax, it's better to 
have a generic syntax designed for overloading by library and 
user code.