Thread overview
The most twisted D code (you've) ever written
Oct 12, 2007
downs
Oct 12, 2007
BCS
Oct 12, 2007
Myron Alexander
Oct 12, 2007
Matti Niemenmaa
Oct 12, 2007
Myron Alexander
Oct 12, 2007
Frits van Bommel
Oct 12, 2007
Myron Alexander
Oct 12, 2007
Frits van Bommel
Oct 13, 2007
Daniel Keep
October 12, 2007
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;
October 12, 2007
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;
	}
}


October 12, 2007
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.
October 12, 2007
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
October 12, 2007
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 ;).
October 12, 2007
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.
October 12, 2007
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.
October 12, 2007
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.
October 13, 2007

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.