I would ask someone to convert all posts in /prog/ to both formats, and then see which format, on average, produces shorter strings. I will not do this because I'm lazy.
If you really want to get your changes into the SexpCode standard, it's probably more effective to discuss them in #bbcode.
This particular suggestion is awful, though.
>>8
And that's stupid. It's in violation of a million years of mathematical convention. It's as stupid as that guy on {b Xarn}'s blog suggesting SexpCode should be using commas instead of periods because that's how CSS does it.
fg(x) is equivalent to \t. f(t)*g[x](t). Read SICM they use this notation all the time
Name:
Anonymous2010-06-27 19:27
Read SICM
Name:
Anonymous2010-06-27 19:36
>>6 . is the function composition operator, not some mere tag delimiter.
Null-space is being using as the composition operator in the proposed SexpCode, while dots are being used as delimiters for the functions themselves (and ``functions'' longer than 1 character at that). Do you understand?
>>40
As long as you don't start a block FV-style with some SexpCode function masquerading as a type, you'll be fine.
Name:
Anonymous2010-06-28 9:31
This thread is a disease.
Name:
Anonymous2010-06-28 13:46
>>43
Unless you're using a particularly strict implementation of SexpCode, of course. The ``correct'' way of posting C code is to use one of the verbatim syntaxes, possibly in composition with a code function.
Shouldn't a post be in verbatim mode by default? There's always less formatting than plain text, so why not say ``I wish for this portion of text to be parsed for formatting please'' instead of ``I wish for this portion of text not to be parsed for formatting''?
>>46
The curly braces specify what parts of your post you want to be parsed for formatting. The verbatim modes specify when you don't want the thing that would normally specify that you want something to be parsed for formatting to specify that you want something to be parsed for formatting.
{define bi #}{define o i}{define bio m}{define u rem}{define biou aa}{.biou what happens now, asshole?}
I know what you're going to say should happen, but you can spare it, because whereas the code was explicit before, you've decided to add a mind-reading element for no reason. You are a stupid, arrogant faggot and IHBT.
>>57
Aha, you're right. What a joy all that extra syntax is.
Assume I instead wrote .define, .aa, .rem, etc. I could end up with:
{#i.rem what happens now, asshole?} {m.rem what happens now, asshole?}
or [code]{.aa what happens now, asshole?}
All three would be perfectly valid; resultant behavior would depend solely on whether or not a given parser implementation is lazy or greedy in its function evaluation.