Carrot Programming

With Carrot you have $expressiveness

Frequently Asked Questions (FAQ) with answers


What is Carrot Programming about? - Q101
Carrot turns expressiveness from a vague idea into a programming tool identified by $expressiveness. The dollar in front of it means its a Perl variable. As such expressiveness is on the same level with graphical user interface elements, file operations or plain data.
What is the goal of Carrot Programming? - Q102

Carrot introduces expressiveness into Perl 5 systematically. That leads to better communication among programmers and allows for larger applications to be written in Perl 5.

Note that $expressiveness is not always visible, though it exists for every package and performs work in the background.

What is the problem with bigger applications? - Q103

The issue of non-communication is most prominently documented by the article on How Perl Saved the Human Genome Project. Which rather illustrates how Perl threatened the project in the first place and which organisational measures saved the project by restoring communication. The article is a strong argument against the use of Perl 5 in larger projects.

The Human Genome Project was a public project and had a private competitor called Calera. That company developed a faster algorithm for processing the measurements. With their algorithm plus the research results of the Human Genome Project, Calera was able to achieve the goal of "completely" sequencing the human genome before the public project did. Though Calera massively used research results obtained by the Human Genome Project, they did not use its Perl code.

Is Diversity a fancy name for source code filtering in Perl? - Q104

Diversity mainly happens before source code filtering and is still present during and after. Thus both can't be the same, though both generate source code.

Diversity defines simple interfaces for source code generation and uses a set of plugins and plugin-plugins which are object oriented. Some plugins might even filter the code. Like the one for the INCLUDE{} block, which replaces the block with the contents of the resulting file name. However, Perl hasn't loaded the module file as a module file, yet. And Perl won't load it. Diversity triggers a series of temporary files and in later program runs the last in the series might be optimized and permanent. That allows for expensive processing steps to be performed.

Is Modularity a fancy name for source code filtering in Perl? - Q105

Modularity mainly happens after source code filtering and is even present before. Both can't be the same. Don't be confused by the generation of source code. It happens once for the first program run only. Modularity 'happens' at every program run.

Is Expressiveness about generation of source code? - Q106

Individuality can't generate source code, because the code is already running. Modularity permanently stores generated code and is still present. Thus code generation can't be the main purpose of $expressiveness.

What is the difficulty in understanding Carrot? - Q107

The difficulty is the same as in understanding a Queen or a King. If she can't cook a lunch for you, what is the benefit of a queen? If he can't fix your car, what is the benefit of a King? Obviously such rhetoric viewpoints don't apply. Sovereigns perform functions different from ordinary people.

Carrot creates the sovereign $expressiveness, which delegates all practical ordinary work to plugins. Which might further delegate to plugin-plugins and even plugin-plugin-plugins.

How is Expressive Power related to Expressiveness? - Q151

Expressive Power can be an assessment of expressiveness. Expressive Power might be an analysis which types of problems (algorithms) can be expressed with a given language or linguistic instrument. While expressiveness (in Carrot) is either one of diversity, modularity or individuality. Never their (vector) sum or anything else. You can't have $expressive_power in the same way Carrot provides you with $expressiveness.

What is extended (or generic) Object Orientation? - Q152

Somewhat over-simplified: classic Object Orientation is the combination of methods and attributes in one file. That's code centric. Extended Object Orientation as implemented in Carrot for Perl recognizes associated files and their domain specific data.

Reflections - Ask yourself

Is my project big enough? - Q201
A typical Carrot configuration loads some 100++ modules before payload is considered. Which doesn't really matter (in terms of resource consumption), if your actual application uses them anyway and loads even more modules.
Do I appreciate development? - Q202
Carrot distinguishes programming and development. Programming is a low-risk short-term decision. Development is the opposite in this simplified perspective. One is not better than the other. Their mix depends on individual goals. However, there is a strong development component in Carrot, which might be experienced the first time.
Is Perl 5 conservative enough for me? - Q203

As a rule of thumb an application purely written in Perl 5 roughly takes 100 times the hardware resources (CPU, RAM) compared to an application purely written in C. That's not always a critical, but should be kept in mind.

Why is Perl 5 used at all then? Because Perl can be more economic when it comes to development resources, which might be more expensive than hardware. Beside that, the user interface of the author's DSL router is implemented in a 'fast' language (not C), but the result is annoyingly slow. In short, the language is not everything.

Do I need more data integrity than Perl 5 can offer? - Q204

Perl 5 has an excellent memory integrity. But no application data integrity comparable to SQL or C-derivatives.

Am I stuck to older versions of Perl 5? - Q205
Carrot requires version 5.18 or better. Older versions have severe bugs which would be expensive to support. Interest in taking over the expenses fully and permanently hasn't shown up. Discussing anything before 5.18 is futile.
Do I want to change everything except Perl 5? - Q206
Carrot aims at application-wide consistency. It doesn't aim at adding single isolated features to existing projects.
Can I type fast enough? - Q207
The length of identifiers often goes beyond 10 characters. A certain speed and efficiency in editing longer texts is required.
Do I prefer One-Liners? - Q208
Many package names occupy 'one line', meaning on a 80-characters wide terminal. In other words, with Carrot 'one line' might be already occupied with administrative overhead and can't carry payload.
Am I confident with an amount of 400 files? - Q209
You need strategies different from reading all files. Carrot isn't a novel: a linear story you could read from the first to the last page.

General Statements and Advice

Intensity: I believe that Carrot is too .... - Q251
Generally it's easy to find any such a perspective in a big project. Shrinking the view to isolated aspects is a valid approach for comprehension and quality control. But when it comes to a valuation, the question is also: is too ... for what?
Simplicity: In my opinion Carrot is trivial, it just does... - Q252

Thank you for the compliment. It was hard work to achieve a 'trivial' appearance for a few dozen features. Carrot relies just on a few principles which can be easily mastered (assuming there is actual use for the principles).

If you actually think it just does... and it just does... and it just does... and it just does... and so on a few dozen times - then you probably got the point.

Resources: You should do ... to save resources (time, memory). - Q253
Fine. Demonstrate the savings with a relevant script. It's not enough to cite the Perl documentation, because that is sometimes out of sync with actual performance numbers.
Overhead: It seems Carrot contains too much overhead. - Q254

Big projects are managed by controlling the relative overhead, not the absolute.

Of course the ground works for a high-rise building take more effort than for a double storey house from an absolute point of view. But the ratio of ground work per apartment is better in a high rise building.

Beside that, overhead is just a perspective from a lower conceptual level. Overhead is seldom saved but often moved out of sight - growing and waiting for a chance to kill the then de-armed project.

Style: For me Carrot code is difficult to read. - Q255

There are more than 10.000 statements in Carrot. Make sure not to read most of them. You just need the right attitude, style, and tools in order to succeed.

Some popular coding styles promote complete linear reading, i.e. from the first character of a line to the last, from the first line of a file to the last, and from the first file of a project to the last. Together with fewest parenthesis and a two-character wide indentation the layout appears almost like a printed book. However, Carrot is too big for linear consumption. You have to jump through the code, ignoring most of it. Parenthesis and outstanding indentation assist that.

An essential tool for not reading is syntax highlighting. It assists your eyes in jumping around. Doesn't work for you? Then your editor might only provide text coloring. That has the opposite purpose: relaxation of the eye. You'll feel pleased but won't get more work done with text coloring. Make sure you have a high-quality syntax highlighting.

Distinction: I identified redundant concepts in Carrot. - Q256

Looking into ::Meta:: can be confusing. So don't do that. Features which are about to be implemented can't be used at the same time. Hence a certain amount of redundancy can't be avoided.

[Conceptual levels aren't completely indicated by package names. Though package hierarchy ::Meta::Greenhouse indicates an early level, it's not a complete description. The levels form a multi-dimensional network of what is shared when and what not. But the file system only has two dimensions. While an encoding could be possible, its inertia would harm development. Some newly developed concepts would be out of reach because the current concept is set in stone (encoded in file names).]


Why Perl 5? - Q301
It has nothing to lose. For example, the block modifiers representing a good portion of diversity could be considered a threat to the minimal style of Python.
What are the design guidelines for Carrot? - Q302
  • Have only as many design guidelines as you can handle in terms of amount and complexity. (Self-integrity)
  • Keep it super simple (KISS).
  • Allow for cheap automation. (Not for the latest fashion in hiding or encoding information.)
  • Impress with interfaces, not with implementations.

Well, that's it. You still remember #1, right? Stopping with four design guidelines is a conservative choice. It increases the chance for the guidelines to be more than lip service. However, don't ever admit you have only these few design guidelines. Tactically it's more wise to pretend you follow the 487 rules of Perl wisdom.

KISS should not be confused with typing effort. Simplicity might be more or less effort to type. For example, it's simpler for every subroutine to have an explicit return statement, though that is more effort in terms of typing characters. But there are more than 2000 subroutines in Carrot and Mica and if you wondered whether all of them correctly return a value, you'd spend more time for debugging than for typing. The standard stack trace only shows the calling not the returning values. It's definitely simpler to type the fixed character sequence r-e-t-u-r-n than to follow the varying sequence of return values triggering a bug in the 40th call frame (or beyond).

Why is there no strong type system in Carrot? - Q303

Mainstream languages have types for two purposes: execution speed and integrity checking. Both don't conflict if integrity checks happen before execution. However, the combination of speed and integrity is a all-or-nothing business. Unless the whole language strictly enforces types, you loose either high speed or guaranteed integrity. Or both, like in Perl 5.

Carrot provides integrity checking at compile time. But not with a type system. An unknown attribute like $this->[ATR_ASDF] will be fatal at package compile time. Which, unfortunately, is often enough the run time of other packages already. But still the program is not in full swing, so the error will probably show up upon program start, and not after hours and a few instructions before the final result was computed.

Carrot also has a loose type specification for subroutines (and packages) for the purpose of faster debugging. Meaning that the system is activated only for debugging purposes and slows down the runtime a lot then. It's meant for bugs which are difficult to spot otherwise. Most bugs in Carrot are easy to spot.

How was modernity handled in the past? - Q304
It was ensured through reckless changes.
How should that work in the future? - Q305
Different, of course. That will be settled once beta maturity is reached.


What is the difference between...
... constructor() and indirect_constructor()? - Q401

Answer as perl code:

my $instance = $package_name->constructor;
- or -
my $instance = $package_name_instance->indirect_constructor;  # calls the above

This distinction is required due to a DWIM-limitation in Perl 5: class and instance methods are treated the same by the language. The constructor could distinguish both only with a general performance penalty.

... destructor() and DESTROY()? - Q402
The destructor has to be called explicitly by the programmer. DESTROY is automatically called by Perl. The challenge of DESTROY is, that it also gets called during the shutdown phase. The object in question might already be half-destroyed. While before destructor, the integrity of the object can be assumed to be intact.
... and - Q403

The file is automatically created by ::Meta::Monad::Managed_File and its content is managed by various plugins. It contains global, local and familiar constants.

The file manual_modularity is manually created and contains only global and local constants. However, the latter can be maintained by an external script.

... between .ini and .cfg? - Q404

dot-ini is for initialization of Carrot. It recognizes a handful of data types by their hardcoded format. For example, something ending with a slash is a directory. There are only file and directory names, package names and hierarchies, associations and separated values.

dot-cfg allows the declaration of data types, sources, and structures.

... between ->advocate and ->oppose? - Q405
Problems of usage or supplied arguments should be handled with ->oppose and the rest with ->advocate. A different view is: if you want to emit caller information, only then use ->oppose.
... between $expressiveness and $meta_monad? - Q406
$meta_monad is the $expressiveness of a foreign package (in plugins).

Particular Constructs

What is the benefit of class names as objects? - Q451

Three practical reasons.

One, it allows a new syntax for class names. A leading :: indicates a relative package name and a trailing :: indicates a prefix, for example. This strategy enhances expressiveness for a group of long class names. Compare the following two blocks:




Two, a mapping might be applied to the names at run time. This lets you configure which classes are actually used without changing the program code. Take note that mapping applies to absolute class names. Relative names are resolved before mappings are applied in the resolution process for package names.

Three, package loading and checks happen in one single place, making audits easier.

Originally the prefixes could be nested. But this feature has been removed. The required << for pop'ing the last anchor from the stack was considered 'not simple' and used only a few times.

When to use $class_names and when $package_resolver? - Q452

Both allow for a level of indirection, i.e. a mapping of requested class name to a new class name. The mapping in $package_resolver is global and the mapping in $class_names is inherited.

Rule of thumb: Use $package_resolver for simple class variables and before $class_names is loaded. Use $class_names for delegated classes.

How to load architecture specific classes automatically? - Q453
Use the placeholder [=os_name=] in the class name.
Why is 'use' restricted to pragmas? - Q454

The 'use' keyword loads another package at compile time of the current package. Because the current package isn't loaded yet, the other package can't refer back to it. Circular dependencies can't be handled with 'use'.

The 'require' keywords loads another package at run time of the current package. Meaning that the current package is compiled and its subroutines are available. The other package can refer back to it for simple tasks. Weak circular dependencies can be handled with 'require'.

Once the $package_resolver is available, even require isn't used any longer.

Why $this->[ATR_SYM] instead of $self->{ATR_SYM()} - Q455

There are two main reasons. The easy one first: it's faster. Processing small numbers is faster than processing strings which even consists of multi-byte characters nowadays. The second reason is that $this->[ATR_SYM] will fail at compile time unless declared. That is a good thing, because typing mistakes like ATR_SYN have no chance. Trivial mistakes are identified at the earliest possible stage.

In contrast to that, $self->{ATR_SYM()} as well as $self->{ATR_SYM} are evaluated at run time, upon hitting that expression. That's bad, because additional unit tests have to be written to chase simple bugs out from such code.

It seems that in recent versions of Perl the processing of Arrays has become considerably slower. At least in the speed test scripts of the author.

But you could have used $self->{+ATR_SYM} - Q456
While technically possible to give perl a hint about how ATR_SYM is meant, the result looks awful.
Why is ::Diversity::Attribute_Type::Many_Declared::Ordered preferred? - Q457

Because you get the biggest bang for the buck. Higher speed, lower overhead, clear advice. The latter is the strongest argument. If you wanted to access other instances' attributes directly, you'd end up with numeric array indices. Example: $other_instance->[5]. This internal view is unattractive to use, its almost binary. Programmers will rather add an accessor method (at least). In short, arrays don't enforce access control, but clearly advise data integrity.

Carrot offers an even stronger variant of this advice for hashes. The hash keys are randomized strings which sometimes even change. Example of the internal representation: $other_instance->{'bIXsODYWaqtl'}. Somebody who doesn't get the message not to touch such internals is probably in the wrong profession. (Though in most cases playing around with data integrity is an act of desperation due to an incomplete application design.)

Some opinions suggest object orientation to be about data encapsulation. But there is no meaningful standalone definition of such a thing for non-trivial cases. Such is the common case of instances logically containing other instances. It's impossible for the outer instance to manage all access to inner instances in general. Consequently decapsulation has to be added to 'encapsulation' - you end up with access control.

Now, access control is far less comfortable than a vague idea of encapsulation. It's less comfortable, because access control is so easily challenged in Perl 5. Actually its advisory only, because every part of a program has control about other parts' namespaces. The point of Carrot is: if more control can't be enforced anyway, then minimize the effort.

Isn't ECS_OS_SIGNAL_ALARM too long to type? - Q458
Touch typing allows you to think while typing. That shifts considerations from length to expressiveness and namespace use.
Why is it required to reset 'each'? - Q459

Because the global state maintained by 'each' might be unpredictable. This is in contrast to 'foreach', which maintains a local state.

Can you be absolutely sure that each(@$a) hasn't been called before? If not, then you have to reset. That easy.

Avoid 'each'. Use something from ::Personality::Reflective::Iterate:: instead.

You should use more builtins, they're more efficient than methods. - Q460
On the average one method stands for several builtins. Therefore it makes no sense to compare one builtin with one method.
Why the effort of return(PERL_FILE_LOADED)? - Q461

Try the following code and wonder why 3 is a problem, but 1 and 0 aren't.

use warnings 'FATAL' => 'all';

Shouldn't all three throw an exception? Yes, of course. But the first two are required to do what return(PERL_FILE_LOADED) does. Ouch!

Package Naming

I found a naming which isn't perfect. - Q501
Perl package names correspond to a directory tree on the hard disk. Forming a formally and semantically perfect tree might be possible for static trees. But every day new packages appear, so the tree of package names in Carrot is dynamic. It means that a perfect naming may no longer be perfect even the next day. The ratio of effort to life time should be kept in mind for re-naming requests.
Naming should be more obvious on higher levels. - Q502

Subject categories have been selected as one of the directory structures for CPAN, but that turned out not to be obvious at all. Today the categories have little practical value left. Instead you approach CPAN by full text search. That's a lesson to be learned. An obvious naming scheme is easier said than done for a few hundred or thousand files.

There are two challenges. One, a directory tree allows only for one sorting key, but different developers have different opinions on what an obvious sorting key is. Two, a directory tree for package names is partly static due to external references to it. Chances are low that a naming can be found, which addresses the two challenges.

Names should be less deep. - Q503

Should you have difficulties in understanding Carrot, you will have either way. Whether 300 files are stored flat in one central directory or in a hierarchy of subdirectories. But with a flat organization, you'll miss any suggestion how the files interact with each other. Thus the idea of a less deep structure alone is meaningless.

Many Perl projects have package names with only one or two levels of hierarchy. But these contain fewer files to manage. As of writing there are 330 .pm files in Carrot. It takes five levels of subdirectories to organize them, assuming every subdirectory contains three items. That's what you can observe in Carrot on the average.

Names should be shorter. - Q504
They can be automatically shortened to one or two characters by one of the obfuscating source filters.
The style of package (class) names? - Q505
Branch components should be one-word singular forms. The actual name can be two-word plural, if it makes sense. Examples: ::Personality::Valued::File::Name::Type::Regular # note singular "Type" ::Modularity::Manager # note plural ending

Method names

The style of method names? - Q551
The name should express the action and its complexity should indicate what is affected by the method. The instance, the arguments, or both? By default method names should be simple and the action should refer to the instance. If the action rather refers to the arguments, then the method name should contain an additional attribute. Examples:
	$this->assign($value); # assigns to $$this
	$this->assign_into($value); # assigns to $value

The style of method names? - Q551
+_value  means a plain (scalar) value argument
+ed means something is returned (not an in-place modification)
+_ means the argument is modified, not the instance

Fashion and Life Style

Please sprinkle more syntactic sugar on Carrot. - Q701

Sweet taste indicates a concentration of certain nutrients and allows for fast nourishment. Similar to food, a piece of code is considered sweet if it uses a concentration of language constructs and allows for faster programming. In short, the promise of syntactic sugar is less typing effort. The idea has a long tradition and it's more conventional name is shorthand writing.

However, recognizing syntactic sugar as shorthand writing immediately kills the innocence of the idea. With shorthand, you simply invent new syntax and semantics as you need them for fastest writing. It's an excellent mental training. Obviously the shorthand of different authors can't be mixed. In other words, you can sprinkle only once for meaningful taste. Beyond starts burying. The idea of syntactic sugar is fine, but the expectation to repeatedly 'sprinkle' on a single cake isn't. The alternative promoted by Carrot are individual cakes.

Carrot promotes domain specific languages in separate files. These allow for a degree of concentration one could never achieve with syntactic sugar on top of Perl 5. That's why Carrot rather suggests a reduced Perl 5.

One could mix domain specific languages in a single file, the main perl module. But that'd be unprofessional. It'd be the singularity trap of Perl: one author with one editor writes one mixed-format file. Specialists collaborating on separate specialized formats with the help of many advanced tools prospect a better quality result.

Is there support for old releases of Perl 5? - Q702

Organisations which are stuck with old versions of Perl are disappearing. Either by organisational breakdown (being stuck is a sign of weakness) or by replacement of Perl, meaning they vanish as Perl users. It makes no sense to invest into either case. Misconceptions and bugs in older releases of Perl are simply too costly to support and have no common benefit. As long as the author gets segmentation faults from the core modules, Carrot and Mica won't take a certain release as a long-term reference. Though 5.18 is the best version of Perl 5 the author ever encountered.

What about more code re-use from other projects? - Q703

Code re-use is a meaningless idea in the absence of clear aims. If you need a tree-sort then you can't re-use a bubble-sort, though both is about sorting and can be represented with an abstract sorting API. The modules associated with Mica are unique in nature. They couldn't be efficiently replaced by what was available on CPAN before. Not everything with a round shape is the same old wooden-style wheel.

Beside that, the modern world is based on the fact that the wheel was and is constantly re-invented. Not generally but technologically. How would a modern car perform with wooden style or even stone wheels? Even the best wheel types for bicycles won't work on a car and vice versa.

Why didn't you facilitate more modules from CPAN? - Q704

There are over 20.000 projects on CPAN. At a first glance it might be irritating that Mica ships its own breed for similar looking purposes. Then again CPAN is a competitive place. It happens that 20 different projects compete for the same idea. Competition has led to amazing features in the projects related to asynchronous events, for example.

CPAN manages quantity, not quality. You'll find something on most topics. But pick any project from it and the quality will range from undocumented faulty sketches to shiny proven products.

Why didn't you use module X::Y::Z? - Q705

Try one of these:

  • It wasn't yet available when I checked.
  • It didn't have the required features when I checked.
  • I didn't find it. Looking at the amount of duplicate work on CPAN, I'm not the first not to find something.
  • Evaluation would have taken more time than simply writing it myself. Consider how trivial many modules are.
  • It'd depend on many other modules.

Still I put a lot of effort into evaluating CPAN modules. Just to be on the safe side. For example, before Carrot::Productivity::Text::Placeholder was assembled, all the template modules were evaluated. Nothing suitable was found. However, there is no continuous re-evaluation, so from today's perspective there might something suitable.

Why don't you use the module - Q706
Modules with hidden or direct insults, personal beliefs, political propaganda and marketing statements are not considered at all. That also applies to names like or Experience shows that the quality of such modules is contrary to their name.
You should really use, it makes Perl 5 more like C++/Java/Haskell/PHP etc. - Q707

Sure, it makes something out of Perl 5, but does it make sense in this context? Nobody will choose Carrot because it's code appears somewhat similar to Java etc.

Consider that most languages offer speed and robustness at the price of limitations. Perl 5 can't offer that speed, so why bother about the limitations of other languages?

Take Haskell as an example. It's a really great tool to do certain numerical computations at amazing speeds (compared to the effort of programming). At least if you are able to keep side effects out of your code. But one of the main ideas of Mica is to organize side-effects well - not to keep them out. With a more Haskell-like Perl, I could only do things I don't want at the same low speed and at the cost of additional resource consumption. Pointless!

Can subroutine X be made more generic? - Q708

In principle yes, but in the context of Mica probably no. There must be a clear benefit beyond universal principles. A change of generality, whether expanding or limiting, is not a value by itself. But rather a cost factor, which should be avoided.

How to address the diamond problem in Carrot? - Q709

If @ISA of package A contains B and C, then there is no D to form a diamond. End of the story. Digging recursively into B and C to find D violates object integrity. From the viewpoint of A the package B has to be taken as-is.

Now, with C++ you can share memory areas via specially crafted diamond arrangements. Fine, the C++ diamond decision exists due to a singularity. But it's specific to the implementation of instances in C++. The attributes in Carrot are names, not pointers. The problem is void here.

Sometimes the diamond is motivated with the example of an amphibian vehicle, which inherits the wheels from a car and the propeller from a ship. Will propulsion be carried out by either or both? The correct answer is that nature didn't create frogs by crossing eels with rabbits. Nature should know why, it's the most experienced developer on earth. From the viewpoint of design, propulsion is not the added value of a car. Therefore it'll be a candidate for delegation not inheritance. The example of the amphibian vehicle fails basic plausibility checks.

Does Carrot support Aspect Orientation? - Q710

Probably not, because Aspect Orientation appears as a vague marketing vehicle. The theory of Aspect Orientation presents the motivation for monads without mentioning them by name. The associated papers give more questions than answers.

In practice Aspect Orientation is sold as a debugging or patching technique called 'code weaving'. The public examples of code weaving have equivalents in straightforward OO.

The contradiction between theory and practice of Aspect Orientation makes it difficult to say much about it. After all contradictions allow for arbitrary statements. An understanding of Aspect Orientation as two unrelated approaches under the same hood leads to the following comparisons.

Carrot doesn't provide the particular 'code weaving' of practical aspect orientation. It expresses the same with object orientation. Regarding the theoretical approach, Carrot doesn't introduce a new name for monads but presents a theoretical and practical framework for handling them.

Coding Style

How about Perl::Critic? - Q751

The compilation of a set of best practices by D. Conway and the associated Perl module Perl::Critic was a milestone in enhancing the code quality of projects. Conway's best practices provide food for thought and the associated module compares actual code against his recommended best practices.

The potential benefit of a configuration of Perl::Critic for Carrot would be the automated verification of the coding style of contributed patches. However, Carrot has its own best practices, half of which are considerably different from the one found in Perl::Critic. It would be a major effort to create a set of modules and documentation for Perl::Critic.

If Perl had a context-free syntax, then Perl::Critic and the PPP its based on would be more convincing. Seen from a different viewpoint, PPP is an attempt to give Perl 5 a context-free syntax event handling. Too much effort. Carrot targets a more integrated solution within the framework of block modifiers.

How you use tab stops? - Q752

Tab stops are great in combination with file formats which allow their definition. However, on a typical Unix system such formats are not present. Meaning tab stops aren't great under Unix.

Some editors and terminal emulations enable the definition of tab stops on the individual, application or system level. Meaning on the wrong level, because it leads to data corruption if data is exchanged between individuals, applications or systems without exchange of the meta information. It must be done on the document level. As a simple and effective solution tab stops are strictly forbidden in certain projects. That makes sense.

The solution used in Carrot is twice-folded:

  • to use tab stops exclusively for indentation at the beginning of a line, and
  • to assume the traditional default of eight spaces wide tab positions.

Beginners often promote four- or two-space wide tab positions. It gives them a tidy layout even in the presence of ten levels of indentation. Five levels are already a broken design and they want to comfortably go along with double the amount. Broken means, that the code is probably far less modular and less readable than it should be. They start a project on a brilliant day. Heck, on a brilliant day even line breaks stink, give me the code in one single line. Who says one can't read this. But the year is not a sequence of brilliant days. Thus the choice for an outstanding layout which can be consumed even tomorrow.

Is every number replaced by a symbolic name? - Q753

In contexts where a number reflects an amount, it's kept as is.

In contexts where a number represents a fixed array or list index, it's replaced by a managed symbolic name.

Is every string replaced by a symbolic name? - Q754
There are fewer quoted strings in Carrot, not because the quotes have been left out, but because the string is kept in a symbol for re-use. No potential re-use, no symbol.

System Administration

Why the Package-Dot directory? - Q801
It simplifies development. Where to put a file like FAQ.pod? Where to put a file like FAQ-fr.pod? What about a style_guide.pdf? To find individual solutions for general problems is more expensive than a package-dot directory. A bigger software project can't survive without general solutions. The files mentioned belong into ./documentation/
Is Carrot safe against code insertion? - Q802

The construct 'eval $code' executes the contents of $code as Perl code. Which carries the potential for misuse, if the contents of $code could be controlled remotely by anybody on the Internet. Meaning if there was a piece of code which stores the network inputs (or HTML form inputs) in $code without sufficient checking. Intruders will audit the Carrot source code for such opportunities. As this release of Carrot hasn't been widely tested, yet, you should do the same.

Carrot concentrates these kinds of constructs in two packages (this is probably outdated information). The first is ::Modularity::Package::Name::Space and it's restricted to a few hard wired code patterns. It checks for sane parameters for submission. The second is ::Individuality::Singular::Execution::Code_Evaluation and it allows arbitrary submissions. There no direct or indirect connection between network data and it's derivates and these constructs. At least in theory.

There is also the form 'eval { ..code.. }', which is safe with regards to the consideration above. In this form the code is fixed and can't be controlled remotely. You can skip this kind of eval in your audit.

Take note that the .pl files in the Package-dot are also a potential candidate for remote controlled code insertion. The content of these files is dynamically generated by the module ::Meta::Monad::Phase::Begin::Definitions. Any code insertion problem there could escalate through the .pl file (which is require()d).

Why do directories in the .ini configuration have to exist? - Q803
Optional files in optional directories are simply too much. The requirement for existing directories (their creation) reminds about the efforts for support and administration.
What is the advantage of giving a package name instead of a directory? - Q804
Perl will resolve the package name into a file name and that is then used as a directory name (without file name extension).
The file is never compiled. - Q805
Compilation is only done upon exit not die. You application needs to run once without encountering an error. It helps against errors populating into

Error Messages

'Attempt to bless into a reference' - Q901
Change ->constructor to ->indirect_constructor.
'Can't use string ... as a SCALAR' - Q902
Change ->indirect_constructor to ->constructor.
'Bareword "..." not allowed' - Q903
Delete the of the package and try again. The file will be re-created automatically. If there is a file, then manually add the definition of "..." to it. Copy from other files.
'Modification of a read-only value attempted' - Q904
If that is related to ->provide, then an anchor is missing the trailing ::.
'The package dot directory doesn't exist' - Q905
Start the program with --carrot-mode=development. The directory will be created automatically then.


The BOM is discouraged by the Unicode consortium. - Q951
All text files in Carrot carry the BOM. Sure, one should not indicate endianness of UTF-8 encoded Unicode characters, because there is nothing to indicate. But the BOM has been established as a file magic for UTF-8. Editors will recognize a text file as Unicode if it starts with the BOM. Carrot follows that practice.
Why is IS_TRUE+IS_TRUE == 2? - Q952
Carrot can't get a better compromise without modification of Perl 5. Remember that IS_TRUE is just an inline constant. There isn't a compelling reason to define addition on boolean values.
The scalar attribute type violates absolute extensibility. - Q953

So are most Smartphones sold today. They don't feature all the extension slots known from desktop PCs. It's normal that not everything is absolutely extensible.

But.. <hyperventilation>in C++! in Ruby! in Java!</hyperventilation> Even Java doesn't have multiple recursive inheritance (MRI). Oops, Java isn't directly extensible up to the maximum. So what? It's an intentional design decision.

Why is there a shell wrapper script - Q954
Full support for the Unix #!-feature is sacrificed by Perl in favor of DWIM. Perl will run a second evaluation on the #! line. Though the whole idea of the #!-line is that languages should interpret it as a comment. Perl violates this practice and blames others for doing so. Crazy. Probably it's a bug, but that's always hard to tell in the presence of DWIM.
Only the most recent development snapshot is in the repository. - Q955
Fast forward has been the only movement in Carrot. Stepping back to make one feature work again at the price of making ten other features not work? No way. Supporting alpha versions like stable releases? Never. Wondering what revision 137 did? The past has no relevance here. Update: as a compromise, selected snapshots are uploaded to CPAN.
Taint mode isn't supported. - Q956

The general idea of tainting is to control the flow outside-inside-outside (among other things). But the way it's implemented in Perl doesn't qualify as control.

Taint checks in Perl are based on Regular Expressions (REs). The complexity and random appearance of REs contradict the goal of improved and predictable security. In other words, a value might easily be untainted by accident or chance. You can't tell - but telling is the goal of taint checks.

Not to forget that somebody who can't get the parameters for system() right (in a safe way) is unlikely to get the even more difficult untaint RE right. With Perl's taint system, he simply gets more work. Meaning a quantity is introduced. Quality is not touched, but that would be required for improved security.

Carrot Worship

Carrot is great. - Q991
Sure, but don't forget that the Perl implementation is a demonstration in the first place. It'll be much leaner if integrated into the language.
Carrot based code should be double as fast as the corresponding C program. - Q997
Maybe, in special cases. However, for the overall application performance C or Assembler are unsuitable references, because they don't involve the overhead of object orientation. It's known from C++ and Java, both highly optimized languages, that overall resource consumption can't be lower in general.
Carrot should become the next Perl version, Perl 7. - Q998
Don't fall into the Perl 7 trap. Others did before. At the moment any number other than 5 or 6 is unlikely to address the expectations necessary for attraction of developers.