What's the most badly garbled, mangled or otherwise hideously disfigured D code you've ever written that still worked as intended?

The point of this thread is to find out how badly it's possible to twist the D language without making the compiler commit Seppuku.

Note: intentional obfuscation doesn't count :)

Give us your worst.
 --downs

PS: Here's my entry
([&update]~([1, 2] /map/ (int e) { return &prefetch /fix/ (currentStrip
+ e); })) /map/ &Pool.addTask;

Reply to Downs,

> What's the most badly garbled, mangled or otherwise hideously
> disfigured D code you've ever written that still worked as intended?
> 
> The point of this thread is to find out how badly it's possible to
> twist the D language without making the compiler commit Seppuku.
> 
> Note: intentional obfuscation doesn't count :)
> 
> Give us your worst.
> --downs
> PS: Here's my entry
> ([&update]~([1, 2] /map/ (int e) { return &prefetch /fix/
> (currentStrip
> + e); })) /map/ &Pool.addTask;


here is two I like:

#1:  http://svn.dsource.org/projects/scrapple/trunk/bignum/bignum.d


#2: struct TerminalStub
{
	static assert(0 == TerminalStub.tupleof.length, "TerminalStub must have no memebers");


	/**
		This union is used to pack data into a pointer for use when constructing a delegate
	*/
	union pack
	{
		static assert(pack.sizeof == (void*).sizeof, "To mutch data in TerminalStub.pack");
		struct
		{
			ushort l;
			ushort h;
		}
		TerminalStub* TsPt;
	}

	/******************************************************************************
	Eat a given length string from a CodeStream and place a given token in a CodeSequence.

	******************/
	bool TextEaterGeneral(CodeStream ins, CodeSequence code)
	{
		pack pk;
		pk.TsPt = this;

		Token cons;
		cons.type = cast(TokenType)pk.l;

		cons.line = ins.getLine;
		ins.Discard(pk.h);
		code.Append(cons);

		return true;
	}

	/***************************************
	build a delegate with non-pointer data in the this pointer
	
	params:
		t =   The token ID to generate
		str = The string to remove
	***************************************/
	static OperatorParcer TextEater(TokenType t, dchar[] str)
	{
		TerminalStub.pack pk;

		pk.h = str.length;
		pk.l = t;

		assert(pk.h  == str.length, "value is to big: "~.toString(str.length));
		assert(pk.l  == t, "value is to big: "~.toString(cast(int)t));

		return &pk.TsPt.TextEaterGeneral;
	}
}

downs wrote:
> ([&update]~([1, 2] /map/ (int e) { return &prefetch /fix/ (currentStrip
> + e); })) /map/ &Pool.addTask;

What is /map/ and /fix/? Are these valid D constructs? If so, where in the language spec are they as I am very interested in learning more.

Regards,

Myron.

Radu wrote:
> Myron Alexander wrote:
>> downs wrote:
>>> ([&update]~([1, 2] /map/ (int e) { return &prefetch /fix/ (currentStrip
>>> + e); })) /map/ &Pool.addTask;
>>
>> What is /map/ and /fix/? Are these valid D constructs? If so, where in the language spec are they as I am very interested in learning more.
>>
> most likely they are comments; probably striped away by the email client.

They are data types with a defined opDiv and opDiv_r.

See http://paste.dprogramming.com/dpiialjm for something similar.

And that, my friends, defines cool.

-- 
E-mail address: matti.niemenmaa+news, domain is iki (DOT) fi

Myron Alexander wrote:
> downs wrote:
>> ([&update]~([1, 2] /map/ (int e) { return &prefetch /fix/ (currentStrip
>> + e); })) /map/ &Pool.addTask;
> 
> What is /map/ and /fix/? Are these valid D constructs? If so, where in the language spec are they as I am very interested in learning more.

map and fix are struct types with static opDiv_r that return a struct with opDiv, which returns the actual result.
He uses them to approximate infix operators.
He's been polluting #d on Freenode with them for a while now ;).

Matti Niemenmaa wrote:
> They are data types with a defined opDiv and opDiv_r.
> 
> See http://paste.dprogramming.com/dpiialjm for something similar.
> 
> And that, my friends, defines cool.
> 

Ok, I get it. Sneaky but cool.

Thanks for the info.

Myron.

Frits van Bommel wrote:
> Myron Alexander wrote:
>> downs wrote:
>>> ([&update]~([1, 2] /map/ (int e) { return &prefetch /fix/ (currentStrip
>>> + e); })) /map/ &Pool.addTask;
>>
>> What is /map/ and /fix/? Are these valid D constructs? If so, where in the language spec are they as I am very interested in learning more.
> 
> map and fix are struct types with static opDiv_r that return a struct with opDiv, which returns the actual result.
> He uses them to approximate infix operators.
> He's been polluting #d on Freenode with them for a while now ;).

I wonder if there are any plans for adding list comprehensions to D. Not a question, just a musing.

Thanks for the info.

Myron.

Myron Alexander wrote:
> I wonder if there are any plans for adding list comprehensions to D. Not a question, just a musing.
> 
> Thanks for the info.

So am I. (Though in D they'd probably be array comprehensions)

And generator expressions would be pretty cool too. Note: not full generators, those probably can't be done without stackthreads. Generator expressions are a bit more limited, but are a nice syntax to define an iterator that generates elements while opApply'ing over it.

downs wrote:
> What's the most badly garbled, mangled or otherwise hideously disfigured D code you've ever written that still worked as intended?
> 
> The point of this thread is to find out how badly it's possible to twist the D language without making the compiler commit Seppuku.
> 
> Note: intentional obfuscation doesn't count :)
> 
> Give us your worst.
>  --downs

Sadly, I tend to actually try to write nice looking code, even if it happens to be pure evil.

I suppose in that respect, the most terrifying thing I've ever written[1] was a program that compiled new functions at runtime; a proof of concept for turning a delegate into a function pointer that was inspired by Tioport's need to call arbitrary native functions given only a run-time description of their types.  Not bad looking, just really, really evil.

One of these days, I might actually finish it.  :P

Here's the program itself: http://drk.is-a-geek.net/~drk/d/selfmod.d

And here's the in-memory x86 assembler it depends on: http://drk.is-a-geek.net/~drk/d/x86.d

Historically speaking, though, the nastiest thing I've ever done
in-language was probably my collection of function unpacking templates.
 They abused IFTI in the nastiest way I could think of in order to work
out what types a function returned, took as arguments, and how many
arguments it took.

At least Kirk found them useful!  ;)

	-- Daniel

[1] The fake closures stuff comes a close second, though.