Re^4: Unparseability is A Good Thing

Replies are listed 'Best First'.
Re^5: Unparseability is A Good Thing by Zen (Deacon) on Aug 27, 2009 at 13:55 UTC
My paragraph addresses unparsability. I'm guessing you agree in some way, as you are now qualifying the statement. I'd need you to expand on "executing arbitrary Perl code" to answer whether or not it applies to what I wrote.	[reply]
Re^6: Unparseability is A Good Thing by ikegami (Patriarch) on Aug 27, 2009 at 14:12 UTC
I'm guessing you agree in some way, Hold on. Not understanding something does not imply agreement. All I did was to state the problem which was of interest to us. I'd need you to expand on "executing arbitrary Perl code" I'm not sure what you're looking for, so I hope the following helps: To determine the meaning of a token, the parser needs to be able to execute any Perl program, including shelling out to execute any binary. The algorithms executed may be non-deterministic.	[reply]
Re^7: Unparseability is A Good Thing by Zen (Deacon) on Aug 27, 2009 at 15:31 UTC
"The meaning of token" is ambiguous. Do you intend to say the outcome of the token or what the machine is supposed to do with the token? If you intend to say the "outcome", then yes we do disagree on the meaning of parsability. The meaning of the token isn't to play fortune teller; if you give a machine tape input, the machine doesn't pretend to somehow create a pipeline of the future, knowing the state of machine at time t+1. It only knows the state at execution t, where the reader is. This isn't a perl problem. I know you know this. So what is this requirement on the parser that you are saying is a perl problem?	[reply]
Re^8: Unparseability is A Good Thing by ikegami (Patriarch) on Aug 27, 2009 at 16:30 UTC
Re^9: Unparseability is A Good Thing by Zen (Deacon) on Aug 27, 2009 at 21:02 UTC
Some notes below your chosen depth have not been shown here


Think about Loose Coupling
	PerlMonks