Could Implicit Topics be Implemented Cleanly in a Language? [closed]

As it currently stands, this question i开发者_JAVA技巧s not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. Closed 11 years ago.

I was getting bored, so I started cranking out my own HTML templating language in Perl 5.14 just because I could.

This question is about parser implementation of a specific feature and the feasability of a specific language construct which is rare among languages.

Edit: Cruel and completely unnecessary remarks about PHP removed at request.

Edit 2: Turned into a more objective question.

PHP's simplicity at dynamically handling HTML is a strength, despite what any 50000-line framework users may say otherwise.

Regardless, I was thinking about how implicit topics would work in such a language. Perl has them via $_, but they're kinda nasty -- They're inconsistent, must be explicitly allowed by subs via prototypes, and they're exposed to the user via a reference variable, not to mention having to work out which built-ins use them and which ones don't.

What I'm talking about is wiring the concept of implicit topics straight into the language, with some very well defined rules. E.g. all iteration constructs assign it for each element and closures use it for the first argument (an easy way of having Ruby-do block elegance).

Now, here's the key bit: rather than defining a default 'it' variable, you just define strict semantics where the default topic is inferred and where it isn't. For example, a function that has one less argument than expected will use it as the first argument. Or whatever. You don't expose topics via a variable, rather by the language.

In a language like Lisp or Ruby this would be hard to do, since they don't really like language-level constructs like loops and prefer their own ways, whether it be macros or blocks + methods.

But in a language that embraces language-wired constructs like Perl, this could work really well.

But, and here's another thing, the language forces you to explicitly refer to things if there's a new topic being discussed. For example, if you had a for loop, the topic of the inner loop would be its own current element, not the outer current element. Perl users already do this, but other language-users may not be familiar with the concept.

So, could implicit topics be implemented cleanly into a language, with scoped topics that force the coder to be explicit when ambiguous?

This makes sense in English. We digress into subtopics were we discuss something else, and then we 'scope back out' to the 'super' topic and then make it clear the topic is what we were discussing before. It automatically then means the 'super' topic again. Our speech is dynamically scoped!

Also, what would the best way be for me to go about trying to parse this?

---

There are various levels of implicit topics in programming languages.

On the minimal side you have things like Javascript's setting of this and Ruby's setting of self in methods.

At the other extreme you have languages like J where every character imposes actions that implicitly loop around their applied data.

Somewhere in the middle are languages like Perl which provide many implicit actions, but which also allow you to be explicit about anything you need.

All of Perl's foreach constructs (the foreach loop, map, grep) each use $_ as the topic variable. Many builtins in turn use $_ by default. Subroutines use @_ as the topic variable, and several builtins use @_ by default.

I suggest you spend some more time learning about how topicalizers and context are used in Perl to eliminate extraneous and redundant syntax. Because as far as I can tell, everything you are looking for is already a feature of Perl, it is just up to you to use those features correctly, and to discipline yourself to not use features that work against that goal (it is a big language after all, not every feature is designed for terse code).