-3

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?

Brian Tompsett - 汤莱恩
  • 5,753
  • 72
  • 57
  • 129
Louis
  • 2,442
  • 1
  • 18
  • 15
  • 2
    Besides the PHP "remarks" that don't actually bring anything to your "question", you're explicitly asking for opinions on subjective topics, which is off topic here. – Mat Aug 15 '11 at 13:26
  • I also asked how to go about implementing the parser for such a concept. So you're wrong. The PHP bit was a joke -- despite really liking perl, I joke about Perl's readability a lot too. – Louis Aug 15 '11 at 13:28
  • I think the PHP remarks are a little too much, but this could be shortened and made into a real, objective question. – NullUserException Aug 15 '11 at 13:28
  • NullUserException: OK, will do. I suppose my completely-over-the-top deprecation isn't for everyone. – Louis Aug 15 '11 at 13:30
  • 1
    Then rephrase your whole thing, drop the PHP reference, and make your question _specific_. How to implement a parser is an awfully broad question (and very hard topic). Remove the "code readability" stuff too, that's just subjective. Remove the "post your thoughts" type things, those are asking for discussion. – Mat Aug 15 '11 at 13:30
  • Done. But don't you think implicit topics really boils down to readability in contexts in code? BTW, I just want know about parsing topics, not the whole thing per se. I'll get to work to changing it to a real question. – Louis Aug 15 '11 at 13:36
  • I _think_ I understand a bit of what you're talking about, but that last sentence (the question) doesn't really make sens. The parsing part is just the mechanical part of reading the source and translating that to some compilable/interpretable structure. You've got way more work in defining the _language_ and its _semantics_ before you can attack the parsing/compiling and/or interpretation of your "language with implicit topics". This is still, IMO, way too broad and theoretical for SO. – Mat Aug 15 '11 at 13:45
  • Well, I was thinking of storing a reference to the current topic in the execution state's object, and then getting the language parser to request it when it finds areas where it needs it to remove ambiguity. But I was wondering whether pasting the topic into the correct places in a precompilation stage would be better. Or whatever other techniques I don't know about. – Louis Aug 15 '11 at 13:48
  • ROTFLd on a remark on an absence of `LOOP` in Lisp – SK-logic Aug 17 '11 at 07:12
  • LOOP isn't a language-level construct, it's a macro with its own DSL, or at least it is in CL. Of course macros basically are language-level constructs, but I was talking about languages that prefer to wire features in as opposed to providing macros or blocks or whatever else. You could make a 'topics' system via a macro system, seeing as it's a full language compiler, but I was talking in the context of a language with hard-wired constructs like Perl. – Louis Aug 17 '11 at 12:03

1 Answers1

3

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).

Eric Strom
  • 39,821
  • 2
  • 80
  • 152
  • I'm writing a language just for practice, I'm not writing a new language for any serious reason or trying to replace anything. I'm writing it in Perl, so I know how Perl does it, in fact it was Perl that inspired the post. Yeah, I get how topicalizers work in Perl, but I don't think they work very well at all. The $_ variable is seriously inconsistent with regards to use with the built-ins, and it also requires explicitly prototyped subs in order to work properly via the _ prototype element. Not to mention it doesn't play nice with OOP, with indirect object access being crippled in Perl. – Louis Aug 15 '11 at 21:50
  • Just to add, I think that for a language to take the area of topicalization seriously, it needs to wire it into the language's rules, not make it a corner case with a global variable and ad-hoc rules for certain built-ins and specific-subs with specific prototypes. It just isn't that seamless in Perl, despite how much it tried. The fact that you have to ever explicitly mention $_ shows it could have been done better. How about a topic system that uses dynamic scoping to introduce new topics and restore old ones, and that such a system would only allow inferring where the context is clear? – Louis Aug 15 '11 at 21:53