Towards a Decl reboot

In a month, it will have been a year since my last active work on Decl.  At this point, I think it's time to reinvent that wheel again, and start clean; I can always steal the good stuff.

So ... what was Decl?  What should Decl be?  I have a few principles I want to adhere to, and maybe a bit of a plan of action as well.

1. Somebody else is doing better parsing than I am (Marpa), so first and foremost, eliminate my HOP-based parser code, which had performance problems anyway.

2. The internals of Decl are pure cruft.  Now that I know how some of this stuff works, I can do a better job.  I can also do a much better job in providing Decl support for definition of Decl, and better syntactic sugar (thanks to some pointers from Dave Rolsky).  So .. redo that stuff.

3. The use cases for Decl are too difficult.  It has to be easy to define a module based on Decl that I can call from regular Perl without worrying about it being Decl.  (I'm looking at you, Word module.)  Not that calling Decl as an independent language has to be avoided (I know how to define that better now, too), but ease of use has to take higher priority now that I know how I want to use it anyway.

4. I need to be able to define something in Decl and compile to non-Decl-dependent Perl data structures.  If possible.  At least I need to be thinking about that at every step.  Lightweight flexibility.

5. The definition of domains has to be more semantically motivated than it is right now.  All my example domains ended up being horrible jumbles of cruft, with helper functions defined haphazardly and without easy ways to self-discover.  About as non-semantic as I could have done it.

6. Similarly, the placement of all tags into a hard directory is a mistake.  Tag discovery has to work by looking at @INC, simple as that.

7. The basic concepts that I started building into Decl were valid.  Here's a list I've come up with right now; I want to refine it and organize it, and motivate things better.  The kitchen-sink approach is .. maybe too much.  On the other hand, the point of Decl is to provide a framework for representing the cognitive structures programmers actually use in thinking about programs, so ... does unification need to be in the core?  Maybe?

• Parser support
• Events - this should be expanded to a Lisp-like condition system for error handling
• Shell support (text commands) at every object level, including the main program
• Templates and filters and macros.  Oh, my.
• Iterators and lazy evaluation.
• Code munging and generation.  This should do more than I was doing, using templates, probably.
• Output handling up the tree, just started scratching the surface there
• Tabular data and DBI support in the box.
• Hierarchical data, the file system, and walking iterators.
• Text as a special thing, with rich text and so on.
• Handling of the system and command line 
• Control flow and workflow - handle the user in a sophisticated manner
• Logic programming, unification, and matching
• Explicitly represented state machines
• Gulp - explicitly represented data types.  When I want to.
• Assertions and explicitly represented behavioral tests?
• Bidirectional maps.
• If I can figure out how to do it, views of code at different levels of detail supported in the basic language.  Perhaps some system of annotation?

That's a heavy list.  Honestly, there's almost nothing I can take out of the core without feeling as though I'm missing something, and in fact there are some things I didn't put in the core the first time that obviously should have been there (error handling, I'm looking at you).  What I need to do is to write a principled primer of Decl, going down this list and writing example code for each and every thing.  Then make it all work.

Write the tutorial first.  Odd thought.  Here's the first chapter; it's the Hello, world for Decl:

text "Hello, world."

That's it.  By default, text's action is output, and by default, output goes to stdout.  From a semantic standpoint, how could this be any different?