Clambda or the happy hacker C programming environment
Learning common lisp and the power of having code as data and the good experience of having a regular
syntax lead to one fundamental point. Another one is that on top of lisp there is a more pure functional
languish called Qi that inter operates with common lisp quite well. In Qi you have prolog and yacc like functionality
that should be decent and more especially, you can explore and prove type related questions with the sequent calculus.
Finally there is quite a large code-base of C, it is not as large and complicated as c++ and many applications is written
in C. The idea is to explore what you get by marrying CL, Qi and C together into one system. There are some interesting
motivations or ideas explaining why I would like to test this out.
Idea 1, A live code object
You keep a live code object inside the memory that knows of all the types of all the parsing states and everything
in one environment, the macros and facilities you write should be close to the parser and the type manager.
You should be able to do advanced quires and refactoring operations. The integrated programming environment should not be a flashy
gui, it should be a command prompt. The gui, the editor, is just serving as a communicator to the programming environment
and human beings. I chooses to use the common lisp engine as a host. Maybe this is a bad choice, but there is some logic behind
this: the interpreter environment in slime is excellent. I would actually prefer to have an Ipython environment but python
is too slow for my purpose, java and C# is not interpreted. Finally lisp is a good guidance due to
the fact that the task of parsing lisp is on an order of magnitude easier than to parse most other languishes.
Idea 2, C is commonly used why not make it more potent in a new direction then c++ c# and java
In a sense C is simplistic and in many ways a glorified assembler but I actually like it. I usually come to activities
where C is the right languish to use (I need speed and closeness to hardware but the programs is too small to actually benifit from
object oriented programming). People are familiar with this languish so other people might be able to take advantage
of my tool. Basically I will make what I call a programming environment for C, and then later perhaps C++. It will not
be entirely C, but there will be a hopefully clear logical jump from C to Clambda. What I will mainly do is just to kick out the
c pre-processor and then let something more potent enter it's place.
Idea 3 My code should be targeted to be easy for humans to read and walk through and navigate in. My
experience is that I tend to code complex stuff (at work at least) and this coder reads the code not once but 50 times
before the code is debugged, I should not be concentrate on writing fast, I should actually optimize for read speed
and help my own understanding of the code.
Random things that can go into this languish
No operator precedence
operator precedence is a source of bugs, makes it more complex to do a correct parser, makes it more difficult to add
a new operator here and there.
An anonymous parenthesis
a * a+b will be the same as a * (b + c) this particular case should be avoided but
makes significant less cluttered code. This is a clear style choice and should not be difficult to manage usually
writing something like
a+b * c almost certainly never happens in mono space code and a + b * c, will probably
signal an error (to say that + and - can be used together and (* /) can be used together is much much easier
than to specify a precedence order for a ton of variables (look at the C languish the precedence order are there to
capture some common cases in a compact and logical way, not easy). My experience after some experimenting is that
you will decrease the parenthesis overhead to an acceptable limit by allowing this.
We will use infix notation
You can here arguments that it is more difficult to automate code with infix notation. This is basically moot.
we will allow
(+ 1 + 2)
constructs as well as
(1 + 2) In my book the valid reason why to complain about infix syntax is that it is against the style.
The lisp style is to fix the beginning of the parenthesis and then look next to it and in lisp voila you know what
the parenthesis does. On the other hand (1 + 2 + a*b) creates a pattern which your eyes more easily can recognize
without focusing. I want to leave the option open to both forms so that the good programmers can format the code
for good readability. One should use the automatic parenthesing option with care though.
We will signal right to left evaluation of the expression
The main source of right to left evaluation order is the assignment operator. expressions and assignments should give
different signals to the reader without a need to focus. I'm experimenting with the following form of assignment
(-< x = a->data += 12)
The -< operator is a very good operator to show that we are evaluating from right to left, and will mostly be used
together with asignments and it visually gives a special character to asignments.
Lot's of parenthesis
If you think the code is bad because you get parenthesises everywhere you are most probably a sloppy hacker
when coding or did not use the right tool. Always when I feel this about lisp like code I play around with some
formatting of the expressions, aligning stuff, rearrange stuff to organize the code to look better and it does.
This activity of concentrating on style is what I want to promote and is a guiding line in this project. Actually
I think that these kind of activity lower your stress level and frees your mind without loosing too much productivity.
Code should not be too wide, but today we have wide screens!! At some point simplified names for stuff went out of
style. And you know what, I think that this is not entirely good. Because the activity to find good short notions of
something makes the code so much more wonderful with respect to readability. if the text is shorter you find things
much faster and when trying to understand code you need to go up and down with your eyes trying to find stuff you
forgot about. A good coder is someone with short memory ;-) because he need to concentrate on good style. Well actually
short names is really bad for understandability, this is a common fact and the code should
be the documentation in many respects, I do not dispute that. But I will suggest in this languish that you keep your
code in multi column format, and keep one column with fast macros in site of their use, make sure that the ordering
of the macros are well structured and not to many and explore the cool space of short names. Quick macros should be
simple and not too complex and used often - experiment!!! The quick macros will be a pure
pre-processor kind of operation
% ( . = black-color-> )
(-< .part_0 = tzar_e ) % ( _e = _(.tzar-length - 1) )
(-< index = .longlist_Ai ) % ( _Ai = _(A-long-map-name _ i) )
Essentially A nomenclature has to be used and here we have been using . as representing a common structure prepath, _e as
being the end of a special array and _Ai to mean the index i maped to another index via map A = A-long... I do not want
to fix the nomenclature just promote the creation of nomenclature and let people at their taste use them and make sure
that a quick glance to the right can quickly decode the meaning of stuff. Basically if you see a short non
real word at the post or prefix position you will glance to the right to translate. Then at some point things can get
standardized. (Don't use this: my-name_a-long-index. It is terrible to read. The choise of _ as an index operator was
intentinally made to promote the use of the quick macros.)
hyphens as separators
I so much prefer the A-long-file, and the rule is that names should flow at the center line and _ and . brakes
the symmetry at the end causing attention to the post fix and prefixes. If you need to use long names use this instead:
(data->list _ longindex)
See, if you use a long index the overhead of doing this is not much just three characters and it's
much more readable. Actually combining hyphen and minus is uggly so this choise has drawbacks but let's
go for hyphen as a separator.
make it possible to evaluate stuff in reverse order eg present the abstraction and below
present the details in the appendix a simple macro here
Make it easy to use Emacs lisp mode or the slime mode so we do not need to rework the amacs modes too much
Have some name space environments like constructs
Make some kind of demo of a more elaborate extension, introduce a poor mans finite domains for example
Here is a small example code to suggest the syntax, I continually code some algorithmes and experiment with
(defun free (obj_ o)
(let (( .part_ part ( obj-to-part o) )
( uint mask ( 1 << part=>dist) )
( int unlucky? 0 )
( .node_ node ( part-to-node part) ))
(if (full-mask node)
(-< unlucky? = 1 ))
(unset node mask)
(while ( (! node=>mask) && node=>parent )
(-< mask = node=>umask )
(-< node = node=>parent )
(-< node=>mask &= mask ))
(if (mid--unlucky) (update--mid))
(if (head-unlucky) (update-head))))))
(defun report-nfree-to-main ((.node_ node) -> void)
(node=>mem=>tot-free += node=>part-size))
(defmacro full-mask ((.node_ node) -> uint)
(node=>mask == 0xFFFFFFFF))
(defmacro unset ((.node_ node) (uint mask) -> void)
(node=>mask &= ~mask))
(defmacro head-unlucky ()
(if ( osp=>head-addr > _node >= mem=>head-addr ) 1 0))
(defmacro update-mid ()
(-< osp=>head-addr = _node ))
(defmacro mid--unlucky ()
(if (osp=>mid-addr < _node < mem=>head-addr ) 1 0))
(defmacro update-head ()
(-< osp=>mid-addr = _node ))))
The current state is to experiment and try out things.
If there is any questions or suggestions, use the forum on the sourceforge project page for Clambda