www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Parameterized Keywords

reply Patience <Patience.Is Virtue.Life> writes:
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.
Mar 06 2016
next sibling parent reply Lass Safin <lasssafin gmail.com> writes:
On Monday, 7 March 2016 at 05:56:54 UTC, Patience wrote:

 int[size] <- creates an integer of size bits.


You declare arrays of integers with int[size], you know that, 
right?

And I really don't see any useful improvement, that could be 
added with this. It would just be wasted efforts.
Mar 07 2016
parent reply Patience <Patience.Is Virtue.Life> writes:
On Monday, 7 March 2016 at 15:09:48 UTC, Lass Safin wrote:

 On Monday, 7 March 2016 at 05:56:54 UTC, Patience wrote:

 int[size] <- creates an integer of size bits.


 You declare arrays of integers with int[size], you know that, 
 right?


No, not right. Think again. Get your mind out the gutter. Making 
your own assumptions about what I am talking about can get you in 
to trouble. Only in programming languages were int[size] is 
interpreted as an array does it mean that.


 And I really don't see any useful improvement, that could be 
 added with this. It would just be wasted efforts.


You sound very intelligent!!! I'm sure glad I asked you before I 
asked god since you seem to know everything about everything. 
Thanks for the input! I will simple cease to think about progress 
from now on since you have decided that no progress can be made.

Thanks again brother!
Mar 07 2016
next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Monday, 7 March 2016 at 20:54:22 UTC, Patience wrote:

 On Monday, 7 March 2016 at 15:09:48 UTC, Lass Safin wrote:

 On Monday, 7 March 2016 at 05:56:54 UTC, Patience wrote:

 int[size] <- creates an integer of size bits.


 You declare arrays of integers with int[size], you know that, 
 right?


 No, not right. Think again. Get your mind out the gutter. 
 Making your own assumptions about what I am talking about can 
 get you in to trouble. Only in programming languages were 
 int[size] is interpreted as an array does it mean that.


To be fair, this is a D newsgroup and you did not specify that 
you are talking about this as a general concept rather than 
something for D. My first reaction was the same. It's only 
natural to assume you are talking about this as a part of D.
Mar 07 2016
parent reply Patience <Patience.Is Virtue.Life> writes:
On Tuesday, 8 March 2016 at 00:47:10 UTC, Mike Parker wrote:

 On Monday, 7 March 2016 at 20:54:22 UTC, Patience wrote:

 On Monday, 7 March 2016 at 15:09:48 UTC, Lass Safin wrote:

 On Monday, 7 March 2016 at 05:56:54 UTC, Patience wrote:

 int[size] <- creates an integer of size bits.


 You declare arrays of integers with int[size], you know that, 
 right?


 No, not right. Think again. Get your mind out the gutter. 
 Making your own assumptions about what I am talking about can 
 get you in to trouble. Only in programming languages were 
 int[size] is interpreted as an array does it mean that.


 To be fair, this is a D newsgroup and you did not specify that 
 you are talking about this as a general concept rather than 
 something for D. My first reaction was the same. It's only 
 natural to assume you are talking about this as a part of D.


Yes, but that isn't the point. The point is that only retards 
such as Bob takes abstractions literally.

Why does it matter if I used [] or {} or . or \ or <> to 
reference something doesn't exist yet and hence could be defined 
any way one wants? Then be told it is a total waste by someone 
that clearly doesn't have the basic intellectual ability to 
understand abstractions?

Basically: If someone can't understand that a new 
concept/proposition is malleable and not fixed then they really 
shouldn't be discussing it, They need to go back to their 0's and 
1's.

That is, I except someone to have to think about what I'm saying 
and interpret it properly instead of just adding there 2 cents 
and pretending like it's a dollar.
Mar 07 2016
parent reply Bob the Viking <bob viking.bob> writes:
On Tuesday, 8 March 2016 at 04:43:11 UTC, Patience wrote:

 On Tuesday, 8 March 2016 at 00:47:10 UTC, Mike Parker wrote:

 To be fair, this is a D newsgroup and you did not specify that 
 you are talking about this as a general concept rather than 
 something for D. My first reaction was the same. It's only 
 natural to assume you are talking about this as a part of D.


 Yes, but that isn't the point. The point is that only retards 
 such as Bob takes abstractions literally.


I don't, really. I'm pointing out that you have given us far too 
little to have any sensible discussion. Your post is equivalent 
to 'What if cows could fly? Imagine the possibilities.' Yes, 
there may be advantages to flying cows, but if you can't think of 
good ideas, why should the onus be on the rest of us to do that 
for you?



 Why does it matter if I used [] or {} or . or \ or <> to 
 reference something doesn't exist yet and hence could be 
 defined any way one wants?


VGhpcyBpcyBidWxsc2hpdC4g

IOW:
If we are to discuss anything, we need to agree on a language. 
here, we tend to use English, and we tend to discuss in the 
context of D. Feel free to transcend these borders, but say so 
clearly, and don't be surprised if people misunderstand you when 
you don't. Even more, don't act like a total jackass when someone 
does (as was the reason for my somewhat more spirited post 
yesterday).



 That is, I except someone to have to think about what I'm 
 saying and interpret it properly instead of just adding there 2 
 cents and pretending like it's a dollar.


Your opening post fits exactly within this prison you just built 
- you have 2 very vague and unfinished ideas and seem to think 
they are a million dollars. Maybe there's something there, but 
you have failed to show it.

As for the int[size] idea, here's a template that could do 
everything you describe:

template Int(size_t bits)
{
   static if (!bits.isPowerOf2 || bits < 8)
     // use bitfields
   else static if (bits == 8)
     alias Int = byte;
   else static if (bits == 16)
     alias Int = short;
   else static if (bits == 32)
     alias Int = int;
   else static if (bits == 64)
     alias Int = long;
   else
     alias Int = FixedSizeBigInt!bits; // Does not exist yet. 
Please to write?
}

We are now down to one vague idea. Let's kill that off while 
we're at it:

auto possiblyNullRange(R)(R r) if (isInputRange!R)
{
   static if (isBidirectionalRange!R)
   {
     static if (hasAssignableElements!R)
       alias resultType = BidirectionalAssignable;
     else
       alias resultType = BidirectionalRange;
   }
   else static if (...) // And so on for all the different range 
variations.

   alias E = ElementType!R;
   if (r is null)
     return resultType!E(r);
   else
     return resultType!E([]);
}

We could even rename that to q, and we end up with the same 
number of characters: 'foreach (e; q(myRange))' vs 'foreach[?] 
(e; myRange)'.

We now have but a nebulous concept of keywords that take 
parameters, and no idea how to use them. That and your tone are 
what I object to, not your careless use of syntax.
Mar 08 2016
parent Idan Arye <GenericNPC gmail.com> writes:
On Tuesday, 8 March 2016 at 17:28:59 UTC, Bob the Viking wrote:

 VGhpcyBpcyBidWxsc2hpdC4g


Don't post things like this - some of us are Vim users here...
Mar 08 2016
prev sibling parent Bob the Viking <bob viking.bob> writes:
On Monday, 7 March 2016 at 20:54:22 UTC, Patience wrote:

 On Monday, 7 March 2016 at 15:09:48 UTC, Lass Safin wrote:

 On Monday, 7 March 2016 at 05:56:54 UTC, Patience wrote:

 int[size] <- creates an integer of size bits.


 You declare arrays of integers with int[size], you know that, 
 right?


 No, not right. Think again. Get your mind out the gutter. 
 Making your own assumptions about what I am talking about can 
 get you in to trouble. Only in programming languages were 
 int[size] is interpreted as an array does it mean that.


 And I really don't see any useful improvement, that could be 
 added with this. It would just be wasted efforts.


 You sound very intelligent!!! I'm sure glad I asked you before 
 I asked god since you seem to know everything about everything. 
 Thanks for the input! I will simple cease to think about 
 progress from now on since you have decided that no progress 
 can be made.

 Thanks again brother!


Now listen up, you retarded piece of gutter slime. You are 
posting a newsgroup for D, a language in which int[N] does indeed 
indicate an array of N ints. If that's too hard for you to grasp, 
may I suggest you take up gardening or DIY lobotomy?

While your first post contained what might be interesting ideas, 
your complete lack of understanding of what might be a fruitful 
debate makes me skeptical of them, you, and the future of the 
entire human race. Congratu-fucking-lations.


You have five ideas in your opening post, with limited 
explanations for two of them.

Let's start with those two, because it's actually possible to 
divine what they do. I'm going to stay within the D universe, 
since I like it here, and it gives us at least some modicum of 
solid ground.

== foreach[?] ==

Where is '?' defined? Is it a property of the object being 
iterated over? Is it a global (dog forbid)? Is it just plain 
magic, and you're too stoned to make a sensible explanation?

'executes only if there are one or more iterations'. Just like 
every fucking other foreach, then. What in Wotan's beard would it 
otherwise do with an empty list? Or does it somehow only run 
once, so as to make programming even easier to grasp?

'checks for nullity'. At what bloody level? Suppose there's a 
foreach[?] (a.b.c.allthefuckingletters.ð.ü) - is every single one 
checked? When does it check? Suppose allthefuckingletters above 
suddenly becomes ñúll - does this thing crash? Turn the universe 
into soup?

== int[size] ==

I'm going to pretend I didn't see this. It's a feature that 
exists for small N in D, C, C++ and probably other languages. 
They're called bitfields and are as old as the mountains (unless 
you're a young-earth creationist, in which case they're older).


So, onto your other ravings:

== for[32] ==

What the bloody fuck is this abomination? Like above, who has the 
power to redefine the number 32? Is this some Smalltalk inspired 
thoughtbleed where I can change the metaclass of the number 32 
and give it new features? Can I make it a prime?

Without any kind of explanation, this thing is just weird. I 
can't for the life of me imagine what it'd do, why anyone'd do 
it, or why anyone would even think it up in the first place.

== switch[alpha] ==

Now we might conceivably be getting somewhere. So this turns 
'switch' into a black box that may or may not behave like you 
expect to, depending on how junior and/or crazy the implementer 
is?

I can imagine implementing faster struct comparisons in switch 
statements, and one might even use this to do some interesting 
ADT stuff. But even then, why do I need to specify the type? It's 
right there in the argument to switch.

== if[x](x < 32) ==

See this? This is what madness is made out of. This thing says 'I 
pretend to compare x to 32, but I'm actually downloading horse 
porn and telling your girlfriend it's yours'. It says 'screw you 
and your boolean logic!'. This thing is literally Stalin reborn 
as Hitler.

See, it's not redefining comparison, it's redefining causality. 
This is quantum computing gone bad. What in the name of 
Shub-Niggurath could this possibly do that isn't bad? At least 
with 'switch' there are optimization possibilities, and maybe 
some ADT stuff. Redefining 'if' is like Grassmann numbers or 
Discordianism. Down this path lies chaos.
Mar 07 2016
prev sibling next sibling parent reply NX <nightmarex1337 hotmail.com> writes:
On Monday, 7 March 2016 at 05:56:54 UTC, Patience wrote:

 Just curious if anyone can see the use for them?


I believe 'new' keyword can take advantage of this quite good.
For example you can pass memory usage strategy like so:
MyClass mc = new[stream] MyClass();
MyClass mc2 = new[static] MyClass();

Deja-vu? Yes the idea comes from OpenGL. Also it might come in 
handy for other stuff:
MyClass mc3 = new[no_internal_pointers] MyClass();
MyClass mc4 = new[no_compacting] MyClass();
Mar 07 2016
parent Patience <Patience.Is Virtue.Life> writes:
On Monday, 7 March 2016 at 16:29:27 UTC, NX wrote:

 On Monday, 7 March 2016 at 05:56:54 UTC, Patience wrote:

 Just curious if anyone can see the use for them?


 I believe 'new' keyword can take advantage of this quite good.
 For example you can pass memory usage strategy like so:
 MyClass mc = new[stream] MyClass();
 MyClass mc2 = new[static] MyClass();

 Deja-vu? Yes the idea comes from OpenGL. Also it might come in 
 handy for other stuff:
 MyClass mc3 = new[no_internal_pointers] MyClass();
 MyClass mc4 = new[no_compacting] MyClass();



Yeah, Maybe... new seems more like a keyword hack though. Things 
like if and loop are more natural as keywords(I guess since they 
generally have precise meanings in hardware/assembly). If the 
language already has new as a keyword though, it does seem like a 
good way to modify its behavior.
Mar 07 2016
prev sibling parent Idan Arye <GenericNPC gmail.com> writes:
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)* 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)* 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)* end
Loop 3: 1
Loop 3: 2
Loop 3: 3
=> [1, 2, 3]
[5] pry(main)> foreach? nil do|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.
Mar 08 2016