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)* 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.
Mar 08 2016