Re: Perl 5 interpreter

Replies are listed 'Best First'.
Re^2: Perl 5 interpreter by BrowserUk (Patriarch) on Jan 12, 2011 at 08:23 UTC
but writing portable and efficient C code basically requires excessive macro usage. Most, if not all of the macros in perl5 could be replaced by inline functions and be as if not more efficient. Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice.	[reply]
Re^3: Perl 5 interpreter by Corion (Patriarch) on Jan 12, 2011 at 08:25 UTC
Except that Perl also is supposed to compile on C89 (or is that ANSI C, or even K&R?) compilers that don't support inline. And then you'd either get non-inlined functions (which would bring us back to inefficient) or no Perl at all...	[reply]
Re^4: Perl 5 interpreter by BrowserUk (Patriarch) on Jan 12, 2011 at 08:51 UTC
Ah yes. The spectre and drogue of backward compatibility. Does Perl really need to support a 21 year old standard that was superceded 11 years ago? How many people are still confined, other than by choice, to using a C89 only complier? Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice.	[reply]
Re^5: Perl 5 interpreter by moritz (Cardinal) on Jan 12, 2011 at 09:10 UTC
Re^6: Perl 5 interpreter by BrowserUk (Patriarch) on Jan 12, 2011 at 10:52 UTC
Re^5: Perl 5 interpreter by Tux (Canon) on Jan 12, 2011 at 16:06 UTC
Re^6: Perl 5 interpreter by BrowserUk (Patriarch) on Jan 12, 2011 at 18:59 UTC
Some notes below your chosen depth have not been shown here
Re^5: Perl 5 interpreter by Corion (Patriarch) on Jan 12, 2011 at 08:55 UTC
Re^6: Perl 5 interpreter by BrowserUk (Patriarch) on Jan 12, 2011 at 09:25 UTC
Some notes below your chosen depth have not been shown here
Re^5: Perl 5 interpreter by Anonymous Monk on Jan 12, 2011 at 08:54 UTC
Re^4: Perl 5 interpreter by Anonymous Monk on Jan 12, 2011 at 08:35 UTC
But there are so many macros that just replace one name with the same name with things like S_ or PL_ infront of it. I couldn't figure out why such a thing was needed. Also at times variable types like int, char and other terms like like volatile have been custom names through macros. Couldn't understand why that was done.	[reply]
Re^5: Perl 5 interpreter by Corion (Patriarch) on Jan 12, 2011 at 08:43 UTC
Re^3: Perl 5 interpreter by ikegami (Patriarch) on Jan 12, 2011 at 08:48 UTC
Definitely not all. Some macros ("`dXXX;`") create and initialise variables used by one or more other macros. Those macros and the macros that use the variables declared by them couldn't be made into functions without a cost. In fact, these are the only macros that gave me any confusion. The documentation isn't clear as ti what declares what and what uses what. The only other time I've had to look into the macros was to see what exactly is an acceptable input. (e.g. Is NULL ok?) I'm not sure how much more readable inlinable functions would be. Looking down seven levels of functions is no easier than looking down seven level of macros. I imagine most debuggers are better at handling inline functions than macros, though.	[reply] [d/l]
Re^4: Perl 5 interpreter by Anonymous Monk on Jan 12, 2011 at 09:02 UTC
Are Macros only such ways of creating abstractions? Because they are more of a kind of reusable templating stuff. Here one has to do work on more text replacement and substitution and then work on its logic.	[reply]


laziness, impatience, and hubris
	PerlMonks