OK, so I'm sitting here reading the PostScript Language Reference Manual 
(3rd edition).

PostScript seems like a simple enough language. But when you sit down to 
try to *implement* it rather than just *use* it... you discover that 
there are a few simple little statements in the spec that make it really 
quite awkward.

For example, PostScript involves "dictionaries". A dictionary stores 
key/value pairs. The key will usually be a "name" object. However, 
reading the small-print, I discover that a key can *actually* be any 
possible PostScript object.

So, for example, you can push the current graphics state onto the 
operand stack and use THE ENTIRE GRAPHICS STATE as a key! o_O

In other small-print, I discover that "composite" objects are explicitly 
mutable. If you "copy" such an object, it merely copies the reference to 
it. If you mutate the copy object, the original object sees the change 
too. Fair enough...

...except, wait a sec. So you're telling me I can MUTATE DICTIONARY KEYS??

This is highly interesting, since the keys of a dictionary must, by 
definition, be unique. If you insert a key into the dictionary, it 
checks to see if such a key already exists. If so, that key's value is 
replaced, otherwise the inserted value becomes a new entry.

But wait! I can insert a new key, and then mutate it to match one of the 
existing keys. How does *that* work?? Do we now have a dictionary with 
two identical keys? Or does one of the keys get deleted? (Which requires 
monitoring every single object mutation to check whether it's a key 
somewhere.) Or...??

Of course, 99% of all PostScript code actually uses names as keys, so 
all of this is a complete non-issue. But theoreticaly 1% of the code out 
there might actually try to use a font description as a key, and if the 
interpretter is going to work properly, it has to support this. *sigh*

Other amusing edge cases include "/":

- A name is usually executable; by preceeding it with "/", it becomes 
literal.

- The toke "/" by itself (i.e., not preceeding a name) is a valid 
(executable) name.

Trixy Hobbitses!

Post a reply to this message

Invisible wrote:

> In other small-print, I discover that "composite" objects are explicitly 
> mutable. If you "copy" such an object, it merely copies the reference to 
> it. If you mutate the copy object, the original object sees the change 
> too. Fair enough...
> 
> ...except, wait a sec. So you're telling me I can MUTATE DICTIONARY KEYS??
> 
> This is highly interesting, since the keys of a dictionary must, by 
> definition, be unique. If you insert a key into the dictionary, it 
> checks to see if such a key already exists. If so, that key's value is 
> replaced, otherwise the inserted value becomes a new entry.
> 
> But wait! I can insert a new key, and then mutate it to match one of the 
> existing keys. How does *that* work?? Do we now have a dictionary with 
> two identical keys? Or does one of the keys get deleted? (Which requires 
> monitoring every single object mutation to check whether it's a key 
> somewhere.) Or...??

According to the reference page for he "eq" operator, two composite 
objects are "equal" if they point to the same data structure. In other 
words, PostScript seems to work on reference equality, not value equality.

Thus, a copy of a composite object is always equal to that copy, and two 
seperate composite objects are always unequal, regardless of what you 
mutate their values to.

Still a fairly strange design decision, but it doesn't seem *quite* so 
insane now... ;-)

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> For example, PostScript involves "dictionaries". A dictionary stores 
> key/value pairs. The key will usually be a "name" object. However, 
> reading the small-print, I discover that a key can *actually* be any 
> possible PostScript object.

  Welcome to object-oriented programming... :P

-- 
                                                          - Warp

Post a reply to this message

Invisible escreveu:
> For example, PostScript involves "dictionaries". A dictionary stores 
> key/value pairs. The key will usually be a "name" object. However, 
> reading the small-print, I discover that a key can *actually* be any 
> possible PostScript object.
> 
> So, for example, you can push the current graphics state onto the 
> operand stack and use THE ENTIRE GRAPHICS STATE as a key! o_O

Are you sure it's not a hash/id for THE ENTIRE GRAPHICS STATE rather 
than it itself?

Post a reply to this message

Invisible wrote:
> OK, so I'm sitting here reading the PostScript Language Reference Manual
> (3rd edition).
> 

I assume you are already aware of this, but I'll provide a link anyways:

http://circle.ch/blog/p558.html

-Aero

Post a reply to this message

Eero Ahonen wrote:

> I assume you are already aware of this, but I'll provide a link anyways:
> 
> http://circle.ch/blog/p558.html

Why...why...WHY...why would they do this? o_O

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

nemesis wrote:

>> So, for example, you can push the current graphics state onto the 
>> operand stack and use THE ENTIRE GRAPHICS STATE as a key! o_O
> 
> Are you sure it's not a hash/id for THE ENTIRE GRAPHICS STATE rather 
> than it itself?

Check my other post. It uses pointer equality, not value equality. (So 
pushing the graphics state is just as good as allocating an empty array; 
it generates a unique memory address.)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Warp wrote:
> Invisible <voi### [at] devnull> wrote:
>> For example, PostScript involves "dictionaries". A dictionary stores 
>> key/value pairs. The key will usually be a "name" object. However, 
>> reading the small-print, I discover that a key can *actually* be any 
>> possible PostScript object.
> 
>   Welcome to object-oriented programming... :P

LOL!

Maybe you'll appreciate this... Did you know that PostScript includes 
the tail-recursion optimisation?

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Invisible wrote:

> Other amusing edge cases include "/":
> 
> - A name is usually executable; by preceeding it with "/", it becomes 
> literal.
> 
> - The toke "/" by itself (i.e., not preceeding a name) is a valid 
> (executable) name.
> 
> Trixy Hobbitses!

Also fun is trying to write a correct number parser:

- ".0" and "0." are both real number objects (equal to 0.0).

- "." by itself is a name object.

- PostScript allows both "-" and "+" as sign prefixes (which is good). 
Haskell does not, however (which is bad).

Basically, getting the parser to accept only valid PostScript numbers, 
and return the correct value, is proving to be very difficult! :-(

This is what happens when you try to interface your program with 
real-world systems; not everything is simple and mathematically elegant, 
and it makes stuff much harder to code. I'm not giving up though! >:-D

Post a reply to this message

Invisible wrote:

> Also fun is trying to write a correct number parser:
> 
> - ".0" and "0." are both real number objects (equal to 0.0).
> 
> - "." by itself is a name object.
> 
> - PostScript allows both "-" and "+" as sign prefixes (which is good). 
> Haskell does not, however (which is bad).

Now the joy of parsing strings.

Simple, right? RIGHT??

Ah, but you forget about *escape sequences*! >:-]

PostScript supports these:

- Strings are delimited with brackets, not quotes.
- Matched brackets work automatically. Unmatches ones must be escaped.
- \n, \t, etc.
- \\ is a backslash, \( and \) are brackets.
- \100 is an octal character code. (Oh what fun finding an octal 
conversion function!)
- A backslash before a newline discards the newline character.
- Anything else preceeded by a backslash is just itself.

Man my head hurts... Again, 2% of the functionality takes 90% of the 
implementation effort! >_<

Post a reply to this message

>> Other amusing edge cases include "/":
>>
>> - A name is usually executable; by preceeding it with "/", it becomes 
>> literal.
>>
>> - The toke "/" by itself (i.e., not preceeding a name) is a valid 
>> (executable) name.
>>
>> Trixy Hobbitses!
> 
> Also fun is trying to write a correct number parser:
> 
> - ".0" and "0." are both real number objects (equal to 0.0).
> 
> - "." by itself is a name object.
> 
> - PostScript allows both "-" and "+" as sign prefixes (which is good). 
> Haskell does not, however (which is bad).

Ah, but these interact!

Anything that isn't parsable as a number is a name. Therefore,

"0."    -> real
".0"    -> real
"."     -> name
"1.1"   -> real
"1.1.1" -> name
"1e1"   -> real
"1x1"   -> name
"s1"    -> name
"1s"    -> name

Will the insanity never end?? >_<

Good luck writing a parser that can untangle all of that... :-(

Post a reply to this message

> Anything that isn't parsable as a number is a name. Therefore,
> 
> "0."    -> real
> ".0"    -> real
> "."     -> name
> "1.1"   -> real
> "1.1.1" -> name
> "1e1"   -> real
> "1x1"   -> name
> "s1"    -> name
> "1s"    -> name
> 
> Will the insanity never end?? >_<
> 
> Good luck writing a parser that can untangle all of that... :-(

http://xkcd.com/208/

Post a reply to this message

scott wrote:

> http://xkcd.com/208/

Seriously... You gotta love the way this guy manages to draw stick 
figers that have no facial expressions, yet you can tell *exactly* what 
emotion they're having! o_O

Also... Yes, I am very, very glad I'm not writing a parser for regular 
expressions. (My God, think of the massacre...!)

Post a reply to this message

>> http://xkcd.com/208/
>
> Seriously... You gotta love the way this guy manages to draw stick figers 
> that have no facial expressions, yet you can tell *exactly* what emotion 
> they're having! o_O
>
> Also... Yes, I am very, very glad I'm not writing a parser for regular 
> expressions. (My God, think of the massacre...!)

I meant using regular expressions to help in your parser to decipher 
numbers.

Post a reply to this message

>> Also... Yes, I am very, very glad I'm not writing a parser for regular 
>> expressions. (My God, think of the massacre...!)
> 
> I meant using regular expressions to help in your parser to decipher 
> numbers.

I fail to see how a pattern matching language is of help here...

(I already *have* a real parser construction toolkit. The *problem* is 
that the rules I'm trying to puzzle out are quite complex - and not 
fantastically well-documented.)

Still, sooner or later I'll reach this stage:

http://xkcd.com/349/

Post a reply to this message

>> I meant using regular expressions to help in your parser to decipher 
>> numbers.
>
> I fail to see how a pattern matching language is of help here...

Well it seemed from your example, a "number" is quite easily distinguished 
from a non-number.

A number takes one of the four forms (where n is 1 or more digits):

n.n
n.
.n
n

And is optionally prefixed by a minus sign, and optionally suffixed by an 
exponential term, which takes the form E or e followed by an optional minus 
sign followed by one or more digits.

I would use regular expressions to decide if my string matched this form or 
not, but maybe your language/library already has similar functions to do 
that?

Post a reply to this message

>> I fail to see how a pattern matching language is of help here...
> 
> Well it seemed from your example, a "number" is quite easily 
> distinguished from a non-number.

Yeah, maybe.

> A number takes one of the four forms (where n is 1 or more digits):
> 
> n.n
> n.
> .n
> n
> 
> And is optionally prefixed by a minus sign, and optionally suffixed by 
> an exponential term, which takes the form E or e followed by an optional 
> minus sign followed by one or more digits.

This isn't quite correct.

- The optional sign prefix can also be "+" instead of "-" (in both the 
mantissa and any exponent there might be).
- Numbers may also take the form "n#n".

> I would use regular expressions to decide if my string matched this form 
> or not, but maybe your language/library already has similar functions to 
> do that?

Well, given that I already need to cut the string into bits anyway so I 
can modify it so the number parser will accept it, I'm not sure this 
buys me anything. (Haskell's number parser doesn't like "+" as a prefix, 
doesn't like ".7" or "7." as a number, and so forth.)

There is also a whole bunch of "interesting" rules about how token 
parsing works. A PostScript program can take an arbitrary text string 
and ask the interpretter to parse one token from it. Page 703 of the 
PostScript Language Reference Manual states the following facts:

- If the token read is a name object or a number object, and it is 
followed by a white-space character, one whitespace character is consumed.

- If the token ends with a delimiter that's part of the token, that 
delimiter is consumed, and no other characters after it.

- If the token is terminated by a delimiter that marks the start of the 
next token, that character is not consumed.

In other words, if you have "123 456" then the space is consumed, but if 
you have "<123> 456" then the space is *not* consumed. Likewise, if you 
have "123/abc" then the "/" is not consumed. However, "123abc" is a 
single (name object) token.

Looking at all these facts, it appears that the interpretter actually 
uses some simple rule to break the whole input stream into "tokens", and 
then decides what kind of token it is seperately.

I am now reimplementing my parser so that instead of trying to classify 
and split the input at the same time, it splits it first, and only then 
attempts to decide what it just read. I think this is probably how the 
"real" PostScript interpretters work.

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> Anything that isn't parsable as a number is a name. Therefore,

> "0."    -> real
> ".0"    -> real
> "."     -> name
> "1.1"   -> real
> "1.1.1" -> name
> "1e1"   -> real
> "1x1"   -> name
> "s1"    -> name
> "1s"    -> name

> Will the insanity never end?? >_<

> Good luck writing a parser that can untangle all of that... :-(

  I really can't see the problem. When the input contains a sequence of
valid characters (ie. which can form a real or a name), if this sequence
has the form:

    ^[+-]?([0-9]+\.?|[0-9]*\.[0-9]+)(e[+-]?([0-9]+\.?|[0-9]*\.[0-9]+))?$

then it's a real, else it's a name.

  If we translate that regexp to plain English, it means:

- There's nothing before this pattern (which is what the ^ at the beginning
  means), and nothing after it (which is what the $ at the end means).
- The sequence optionally starts with a + or a -.
- After that two possible patterns must appear (the expression in
  parentheses, where the two patterns are separated with the | symbol):
  - A sequence of one of more digits ([0-9]+), optionally followed by
    the dot character (a plain "." has a special meaning in regexps, so the
    dot character has to be escaped, and thus written as "\.")
  - A sequence of zero or more digits ([0-9]*) followed by a dot character
    followed by a sequence of one of more digits.
- Optionally the character "e" can follow, and if that's the case, a real
  (not containing an "e") must follow as well (the whole last part in
  parentheses, with the "?" at the end to indicate optionality).

  In an actual BNF-style parser the rule probably becomes simpler because
the repetition can be removed.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>> Good luck writing a parser that can untangle all of that... :-(
> 
>   I really can't see the problem. When the input contains a sequence of
> valid characters (ie. which can form a real or a name), if this sequence
> has the form:
> 
>     ^[+-]?([0-9]+\.?|[0-9]*\.[0-9]+)(e[+-]?([0-9]+\.?|[0-9]*\.[0-9]+))?$
> 
> then it's a real, else it's a name.

Yeah. As I said, I'm currently changing my design from one that attempts 
to recognise and delimit numbers to one that just chops the text into 
chunks, and *then* decides what kind of thing each chunk is.

>   If we translate that regexp to plain English, it means:
> 
> - There's nothing before this pattern (which is what the ^ at the beginning
>   means), and nothing after it (which is what the $ at the end means).
> - The sequence optionally starts with a + or a -.
> - After that two possible patterns must appear (the expression in
>   parentheses, where the two patterns are separated with the | symbol):
>   - A sequence of one of more digits ([0-9]+), optionally followed by
>     the dot character (a plain "." has a special meaning in regexps, so the
>     dot character has to be escaped, and thus written as "\.")
>   - A sequence of zero or more digits ([0-9]*) followed by a dot character
>     followed by a sequence of one of more digits.
> - Optionally the character "e" can follow, and if that's the case, a real
>   (not containing an "e") must follow as well (the whole last part in
>   parentheses, with the "?" at the end to indicate optionality).

...which would be incorrect then, for at least the following reasons:

- There can be *zero* or more characters before the decimal point. (But 
notice that there must be more than zero characters *in total* before 
and after the decimal point. It's just that there can be zero in either 
place, but not both.)

- The "e" can also be "E".

- The exponent is an integer, not a real.

See? Not as easy as it looks, is it? Gotta pay careful attention to 
*exactly* what the manual says is and isn't permissible.

>   In an actual BNF-style parser the rule probably becomes simpler because
> the repetition can be removed.

It would be *really nice* if the reference manual included a BNF syntax 
diagram... :-S

Between the rules for splitting up tokens, the tricky rules for escaping 
things in strings, and characters that have multiple meanings depending 
on context, it's really quite hard!

E.g., "<" is the start of a string, "<~" is the start of another string, 
and "<<" is an ordinary name object. Go figure. Similarly, "[" is 
classified as a "delimiter character", yet it's also the *name* of an 
operator (and a name is a sequence of "regular characters" - that is, 
can't contain delimiters).

It all gets confusing very fast...

Post a reply to this message

Orchid XP v8 wrote:
> 
> Why...why...WHY...why would they do this? o_O
> 

Why not? After all, it's possible.

-Aero

Post a reply to this message

Orchid XP v8 wrote:

> Why...why...WHY...why would they do this? o_O

I wonder if anybody will figure out where this is quoted from...

Post a reply to this message

Invisible wrote:

> - There can be *zero* or more characters before the decimal point. (But 
> notice that there must be more than zero characters *in total* before 
> and after the decimal point. It's just that there can be zero in either 
> place, but not both.)

A quickie C# example ...

Code:


     class Program
     {

         static string[] tokens = new string[] {"0.", ".0", ".", "1.1", 
"1.1.1", "1e1", "1x1", "s1", "1s"};

         static void Main(string[] args)
         {

             Regex rx = new 
Regex(@"^[+-]?(([0-9]*(\.[0-9]+)?)|([0-9+]\.))(e[0-9]+)?$");

             foreach(string t in tokens)
             {
                 if(rx.Match(t).Success)
                 {
                     Console.WriteLine("\"{0}\" --> Real", t);
                 }
                 else
                 {
                     Console.WriteLine("\"{0}\" --> Identifier", t);
                 }
             }

             System.Console.ReadKey();
         }


Output:

"0." --> Real
".0" --> Real
"." --> Identifier
"1.1" --> Real
"1.1.1" --> Identifier
"1e1" --> Real
"1x1" --> Identifier
"s1" --> Identifier
"1s" --> Identifier

The relavent portion is this regex:

^[+-]?(([0-9]*(\.[0-9]+)?)|([0-9+]\.))(e[0-9]+)?$

Which does what Warp describes, but also takes care of the case with .0 
and 0.

> - The "e" can also be "E".

you can easily replace the e for exponent with [eE], which allows either 
lower or upper case. :)

> - The exponent is an integer, not a real.
> 
> See? Not as easy as it looks, is it? Gotta pay careful attention to 
> *exactly* what the manual says is and isn't permissible.
> 
>>   In an actual BNF-style parser the rule probably becomes simpler because
>> the repetition can be removed.
> 
> It would be *really nice* if the reference manual included a BNF syntax 
> diagram... :-S
> 
> Between the rules for splitting up tokens, the tricky rules for escaping 
> things in strings, and characters that have multiple meanings depending 
> on context, it's really quite hard!
> 
> E.g., "<" is the start of a string, "<~" is the start of another string, 
> and "<<" is an ordinary name object. Go figure. Similarly, "[" is 
> classified as a "delimiter character", yet it's also the *name* of an 
> operator (and a name is a sequence of "regular characters" - that is, 
> can't contain delimiters).
> 
> It all gets confusing very fast...


-- 
~Mike

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> >     ^[+-]?([0-9]+\.?|[0-9]*\.[0-9]+)(e[+-]?([0-9]+\.?|[0-9]*\.[0-9]+))?$

> ...which would be incorrect then, for at least the following reasons:

> - There can be *zero* or more characters before the decimal point.

  Which is exactly what "[0-9]*\." means: Zero or more digits, followed
by the dot character.

> - The "e" can also be "E".

  That's easy to fix: Replace "e" in the regexp with "[eE]".

> - The exponent is an integer, not a real.

  Then it becomes simpler:

    ^[+-]?([0-9]+\.?|[0-9]*\.[0-9]+)([eE][+-]?[0-9]+)?$

  In fact, that pattern actually matches the floating point number
representation in C and C++ (except perhaps for possibility of a
preceding +).

> See? Not as easy as it looks, is it?

  It was not a question of difficulty. It was a question of me not knowing
the exact format of floating point numbers in PostScript and making
assumptions.

-- 
                                                          - Warp

Post a reply to this message

Invisible wrote:
> There is also a whole bunch of "interesting" rules about how token 
> parsing works.

Sounds like a state machine to me. AKA a regular expression.

Sounds like your parser is too complex.

-- 
   Darren New, San Diego CA, USA (PST)
   The NFL should go international. I'd pay to
   see the Detroit Lions vs the Roman Catholics.

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Sounds like a state machine to me. AKA a regular expression.

  Any regular expression can be converted into a state machine, but can
every state machine be converted into a regular expression? Is there a
one-to-one relation?

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   Any regular expression can be converted into a state machine, but can
> every state machine be converted into a regular expression? Is there a
> one-to-one relation?

In the original definitions of those two terms, yes. Obviously, by the time 
you get to Perl regular expressions, they're no longer "regular" in the same 
sense. If you stick to regular expression algebra as invented by Kleene, 
they're equivalent specifications of the same languages. (One can wind up 
exponentially larger than the other, mind.)

-- 
   Darren New, San Diego CA, USA (PST)
   The NFL should go international. I'd pay to
   see the Detroit Lions vs the Roman Catholics.

Post a reply to this message

Orchid XP v8 wrote:
> Eero Ahonen wrote:
> 
>> I assume you are already aware of this, but I'll provide a link anyways:
>> 
>> http://circle.ch/blog/p558.html
> 
> Why...why...WHY...why would they do this? o_O

Search in povray.general about that guy who wanted to make a webserver in
POV SDL.

(I don't think it's possible without adding for example other I/O
facilities)

Post a reply to this message

Invisible wrote:
> Orchid XP v8 wrote:
> 
>> Why...why...WHY...why would they do this? o_O
> 
> I wonder if anybody will figure out where this is quoted from...

It rings a bell from a Friends episode.

Post a reply to this message

Mike Raiford <"m[raiford]!at"@gmail.com> wrote:
> A quickie C# example ...

Maybe the problem is not so much the PostScript language he tries to
*interpret*, but that Halks... Haks... that hassle of a language he tries to
*implement* it in ;)

BTW - I found PostScript to be one of the most-fun languages to program in...
the whole stack-based approach with reversed notation, the string-handling that
lets you get a substring and then manipulate the *original* string via it, and
so on...

Best thing about it: It usually comes with easy-to-use graphics output :)

Post a reply to this message

clipka wrote:
> BTW - I found PostScript to be one of the most-fun languages to program in...

You should look into FORTH.  PostScript is based on it.

-- 
   Darren New, San Diego CA, USA (PST)
   The NFL should go international. I'd pay to
   see the Detroit Lions vs the Roman Catholics.

Post a reply to this message

>>> Why...why...WHY...why would they do this? o_O
>>
>> I wonder if anybody will figure out where this is quoted from...
> 
> It rings a bell from a Friends episode.

LOL! We have a winner...

I used to have quite a lot of empathy with Chandler. You know - before 
he became all *successful* and stuff... :-/

Post a reply to this message

clipka wrote:

> Maybe the problem is not so much the PostScript language he tries to
> *interpret*, but that Halks... Haks... that hassle of a language he tries to
> *implement* it in ;)

Yes. Of course. The fact that the grammer is ambiguous is only a problem 
in Haskell. All other programming languages are easily able to cope with 
this. :-P

Actually, the problem seems to be the way I've chosen to design my 
parser. (I.e., as a one-pass parser.) Now that I'm redesigning it to a 
two-pass parser, things seem to be going much more smoothly.

(You can design things wrong in *any* language.)

> BTW - I found PostScript to be one of the most-fun languages to program in...

...and you think I'm writing a PostScript interpretter because...? ;-)

> Best thing about it: It usually comes with easy-to-use graphics output :)

Depends on what you think of as "easy".

It makes it very easy to do vector graphics. It makes it rather harder 
to do anything bitmapped.

Post a reply to this message

> -----Original Message-----
> From: Invisible [mailto:voi### [at] devnull]
> >>> Why...why...WHY...why would they do this? o_O
> >>
> >> I wonder if anybody will figure out where this is quoted from...
> >
> > It rings a bell from a Friends episode.
> 
> LOL! We have a winner...

Is that the one where they talk about women sharing?

"I said share, not scare!"

...Ben Chambers
www.pacificwebguy.com

Post a reply to this message

>>>>> Why...why...WHY...why would they do this? o_O

> Is that the one where they talk about women sharing?
> 
> "I said share, not scare!"

Women. They tell each other *everything*.

Yeah, I know.

No, dude, *everything*! I mean like, their most intimate moments. 
Technique. Stimina, Girth.

Why...why...WHY...why would they do this?!

Well, *apparently* it's really great, and we should be doing it too... 
Do you wanna do it?

We're not gonna talk about girth are-

-NO!

Yeah, OK.

...

Post a reply to this message

Invisible wrote:
>>>> Why...why...WHY...why would they do this? o_O
>>>
>>> I wonder if anybody will figure out where this is quoted from...
>>
>> It rings a bell from a Friends episode.
> 
> LOL! We have a winner...

Good lord, I'm on some sort of quote roll here... :)

> I used to have quite a lot of empathy with Chandler. You know - before 
> he became all *successful* and stuff... :-/

"Oh no, two women love me. They're both gorgeous and sexy, my wallet's 
too small for my fifties and my diamond shoes are too tight!"

Post a reply to this message

> -----Original Message-----
> From: Invisible [mailto:voi### [at] devnull]
> We're not gonna talk about girth are-
>
> -NO!
>
> Yeah, OK.
>
> ...

OK, well you know when you're in bed, with a woman, and you start to get 
all these mental images in your head, like, you know, Elle McPherson, or 
that girl from the copy place -

- the one with the belly button ring? -

- and then all of a sudden, your Mom pops in your head!  And you're like, 
you know, Mom, get out of here!  And then of course, after that, you can't 
possibly think of anything else, and you can't, you know, stop what you're 
doing, so it's kind of like you're... you know.. you know... You don't 
know!

- You're telling me, you're telling me about your Mom?  What is the matter 
with you?

- You said -

- I said "share," not "scare!"

...Ben Chambers
www.pacificwebguy.com

Post a reply to this message

"Chambers" <ben### [at] pacificwebguycom> wrote:
> OK, well you know when you're in bed, with a woman, and you start to get
> all these mental images in your head, like, you know, Elle McPherson, or
> that girl from the copy place -
>
> - the one with the belly button ring? -
>
> - and then all of a sudden, your Mom pops in your head!

FAIL

yes, it can happen to anyone. ;)

Post a reply to this message