Skip to main content
Minor typo
Source Link

Divide and conquer

When you're writing a polyglot in a large number of languages, you won't necessarily be able to separate all the language's control flows from each other immediately. Thus, you'll need to "true polyglot" some of the languages for some length of time, allowing the same code to run in each of them. There are two main rules to bear in mind while you're doing this:

  • The control flow in any two languages should either be very similar, or very different. Trying to handle a large number of interleaved control flows is a recipe for getting confused and makes your program hard to modify. Instead, you should limit the amount of work you have to do by ensuring that all the programs that are in the same place are there for the same reason and can happily be run in parallel for as long as you need them to be. Meanwhile, if a language is very different from the others, you want its execution to move to a very different location as soon as possible, so that you don't have to try to make your code conform to two different syntactic models at once.

  • Look for opportunities to split one language, or a group of similar languages, away from each other. Work from larger groups down to smaller groups. Once you have a group of similar languages all at a certain point in the program, you'll need to split them up at some point. At the start of the program, you might well, say, want to split the languages that use # as a comment marker away from languages that use some other comment marker. Later on, perhaps you have a point where all languages use f(x) syntax for function calls, separate commands with semicolons, and have similar syntactic similarities. At that point, you could use something much more language-specific to split them, e.g. the fact that Ruby and Perl don't process escape sequences in '' strings, but Python and JavaScript do.

In general, the logical flow of your program should end up as a tree, repeatedly splitting into groups of languages that are more similar than each other. This puts most of the difficulty in writing the polyglot right at the start, before the first split. As the control flow branches out more and more, and the languages that are running at any given point get more and more similar, your task gets easier because you can use more advanced syntax without causing the languages involved to syntax-error.

A good example is the set {JavaScript, Ruby, Perl, Python 3}; all these languages accept function calls with parentheses and can separate statements with semicolons. They also all support an eval statement, which effectively allows you to do flow control in a portable way. (Perl is the best of these languagelanguages to split off from the group early, because it has a different syntax for variables from the others.)

Divide and conquer

When you're writing a polyglot in a large number of languages, you won't necessarily be able to separate all the language's control flows from each other immediately. Thus, you'll need to "true polyglot" some of the languages for some length of time, allowing the same code to run in each of them. There are two main rules to bear in mind while you're doing this:

  • The control flow in any two languages should either be very similar, or very different. Trying to handle a large number of interleaved control flows is a recipe for getting confused and makes your program hard to modify. Instead, you should limit the amount of work you have to do by ensuring that all the programs that are in the same place are there for the same reason and can happily be run in parallel for as long as you need them to be. Meanwhile, if a language is very different from the others, you want its execution to move to a very different location as soon as possible, so that you don't have to try to make your code conform to two different syntactic models at once.

  • Look for opportunities to split one language, or a group of similar languages, away from each other. Work from larger groups down to smaller groups. Once you have a group of similar languages all at a certain point in the program, you'll need to split them up at some point. At the start of the program, you might well, say, want to split the languages that use # as a comment marker away from languages that use some other comment marker. Later on, perhaps you have a point where all languages use f(x) syntax for function calls, separate commands with semicolons, and have similar syntactic similarities. At that point, you could use something much more language-specific to split them, e.g. the fact that Ruby and Perl don't process escape sequences in '' strings, but Python and JavaScript do.

In general, the logical flow of your program should end up as a tree, repeatedly splitting into groups of languages that are more similar than each other. This puts most of the difficulty in writing the polyglot right at the start, before the first split. As the control flow branches out more and more, and the languages that are running at any given point get more and more similar, your task gets easier because you can use more advanced syntax without causing the languages involved to syntax-error.

A good example is the set {JavaScript, Ruby, Perl, Python 3}; all these languages accept function calls with parentheses and can separate statements with semicolons. They also all support an eval statement, which effectively allows you to do flow control in a portable way. (Perl is the best of these language to split off from the group early, because it has a different syntax for variables from the others.)

Divide and conquer

When you're writing a polyglot in a large number of languages, you won't necessarily be able to separate all the language's control flows from each other immediately. Thus, you'll need to "true polyglot" some of the languages for some length of time, allowing the same code to run in each of them. There are two main rules to bear in mind while you're doing this:

  • The control flow in any two languages should either be very similar, or very different. Trying to handle a large number of interleaved control flows is a recipe for getting confused and makes your program hard to modify. Instead, you should limit the amount of work you have to do by ensuring that all the programs that are in the same place are there for the same reason and can happily be run in parallel for as long as you need them to be. Meanwhile, if a language is very different from the others, you want its execution to move to a very different location as soon as possible, so that you don't have to try to make your code conform to two different syntactic models at once.

  • Look for opportunities to split one language, or a group of similar languages, away from each other. Work from larger groups down to smaller groups. Once you have a group of similar languages all at a certain point in the program, you'll need to split them up at some point. At the start of the program, you might well, say, want to split the languages that use # as a comment marker away from languages that use some other comment marker. Later on, perhaps you have a point where all languages use f(x) syntax for function calls, separate commands with semicolons, and have similar syntactic similarities. At that point, you could use something much more language-specific to split them, e.g. the fact that Ruby and Perl don't process escape sequences in '' strings, but Python and JavaScript do.

In general, the logical flow of your program should end up as a tree, repeatedly splitting into groups of languages that are more similar than each other. This puts most of the difficulty in writing the polyglot right at the start, before the first split. As the control flow branches out more and more, and the languages that are running at any given point get more and more similar, your task gets easier because you can use more advanced syntax without causing the languages involved to syntax-error.

A good example is the set {JavaScript, Ruby, Perl, Python 3}; all these languages accept function calls with parentheses and can separate statements with semicolons. They also all support an eval statement, which effectively allows you to do flow control in a portable way. (Perl is the best of these languages to split off from the group early, because it has a different syntax for variables from the others.)

Source Link
user62131
user62131

Divide and conquer

When you're writing a polyglot in a large number of languages, you won't necessarily be able to separate all the language's control flows from each other immediately. Thus, you'll need to "true polyglot" some of the languages for some length of time, allowing the same code to run in each of them. There are two main rules to bear in mind while you're doing this:

  • The control flow in any two languages should either be very similar, or very different. Trying to handle a large number of interleaved control flows is a recipe for getting confused and makes your program hard to modify. Instead, you should limit the amount of work you have to do by ensuring that all the programs that are in the same place are there for the same reason and can happily be run in parallel for as long as you need them to be. Meanwhile, if a language is very different from the others, you want its execution to move to a very different location as soon as possible, so that you don't have to try to make your code conform to two different syntactic models at once.

  • Look for opportunities to split one language, or a group of similar languages, away from each other. Work from larger groups down to smaller groups. Once you have a group of similar languages all at a certain point in the program, you'll need to split them up at some point. At the start of the program, you might well, say, want to split the languages that use # as a comment marker away from languages that use some other comment marker. Later on, perhaps you have a point where all languages use f(x) syntax for function calls, separate commands with semicolons, and have similar syntactic similarities. At that point, you could use something much more language-specific to split them, e.g. the fact that Ruby and Perl don't process escape sequences in '' strings, but Python and JavaScript do.

In general, the logical flow of your program should end up as a tree, repeatedly splitting into groups of languages that are more similar than each other. This puts most of the difficulty in writing the polyglot right at the start, before the first split. As the control flow branches out more and more, and the languages that are running at any given point get more and more similar, your task gets easier because you can use more advanced syntax without causing the languages involved to syntax-error.

A good example is the set {JavaScript, Ruby, Perl, Python 3}; all these languages accept function calls with parentheses and can separate statements with semicolons. They also all support an eval statement, which effectively allows you to do flow control in a portable way. (Perl is the best of these language to split off from the group early, because it has a different syntax for variables from the others.)