It is helpful to describe some specific uses that the editor would be put to and to see what sort of functionality would be needed for each.
These might include a mail reader, a program editor, a web browser, a word processor with built in spreadsheet, a command-line window, a file browser, etc.
The common thread here is that data is stored somewhere, and displayed and manipulated through this universal editor.
My earlier note about wanting a Better Emacs has left me thinking about more details, and I find that if I don't write them down, they just go around and around in my head. So maybe I'll write them down.
The main parts of the editor would be
It is time that so-called "Office suites" got beyond the spreadsheet.
Spread sheets are a wonderful and powerful idea. I have put them to good use several times. But they are tied to an idea that is no longer relevant - the idea from which they got their name.
A spread sheet is basically an infinitely (or atleast indefinately) large two dimensional table of cells. Each cell can do calculations based on values in other cells. This is great for doing calculations on columns or rows or whole tables. This works really well. There is just one problem.
I've never wanted to have an indefinately large table.
The core operators in this language are the period, used for substructure access, and the parentheses, used to pass parameters to a function call.
Every object embodies a namespace of components and methods. These are accessed by following the object by a period and the name.
Methods can be called by following the name by a (possibly empty) list of parameters enclosed in parentheses. All operations can be called this way, though there are often easier means, such as as infix operators. So for example
Integer.add(a, b)
might be the same as
a + b
Note that this is not necessarily a.add(b). Infix operators are defined as operation in a type, not methods of an object.
When finding which operation to use for an infix operator we look through the operations in the class of the left hand operand which have been associated with the given operator, and choose one for which the types of both sides are correct. Of these, the operation for which the first parameter is lowest in the type lattice is perferred. If choices still remain, the lowest inf the second parameter is chosen.
Thus the virtual class "Number" might declare the "+" infix operator. Then Integer32 might refine Number to a concrete class and define "add(Interger32, Interger32)" which adds two integers. Also Float might refine Number and define "add(Float, Float)" and also "addint(Float, Int)" and "addtoint(Int, Float)" all of which return Float. Then a + b would clearly resolve to one of these providing each of a and b were either Int or Float.
No automatic coersion is done. If another class "BigNum" were defined that defined addition within bignums and between bignums and integers, then an addition of a bignum and a float would fail.
In general, automatic coersion is frowned upon as lack of precission is likely.
Note that classes can define operations and methods for other classes. For example, Float might define a method for the Integer32 class which converts the integer into a floating point number. This is done by declaring the name in the Number class, and defining it for various subclasses.
For this reason, it is good for an abstract class to declare a number of representatons for subclasses to work with. Thus "Number" might declare the names Integer32, Integer64, Float, Double, BigNum, BigInt, Complex, Guassian (Is that what complex integers are called?) Duplex (Complex doubles?) so that different classes can make use of each other representations.
Question: Is this only useful for numbers? Numbers are clearly a fairly special case, but the less special we can make them, the cleaner the language.
Having recently read up on python, I quite like it's syntax. It is clean and not noisy. However I do have some problems with it.
Tuples are a useful construct in a programming language, as long as we know what they are...
A tuple is a fixed collection of other objects. It is different from a list in that it is not extensible: once it has been created, it stays that size. Also, unlike lists, the elements can be of different types. Thus it is more substantially like a Pascal record of C struct.
The value of a tuple over a struct is anonymity. It is sometimes useful to have a struct that is not explicitly typed, but still have enough type information to be passed around safely. Effectively there are standard labels "first" and "second" etc, and type matching is based on substructure matching.
In some languages, such as python, the arguments to a function can be passed positionally or by name. This could be seen as the arguments being a tuple which is addressed either by standard labels (first, second, etc) or by pre-defined names. However argument lists can usefully be of varying length, which is at odds with a tuples pre-defined structure.
UNFINISHED
One of the many schemes that have been proposed to fight junk e-mail is HashCash.
The basic idea is that a HashCash token is a string which a particular property that make is hard to create, but easy to check if that property is present.
The way you use it is to require that anyone who sends you Email, and who isn't on your whitelist, must include a new HashCash token in the mail item. This proves that they have done a measurable amount of work for the privilege of sending you mail.
The value of this is that spammers, who tend to need to send tens of thousands of emails just to get a few responses, would not be able to afford to generate these tokens and so wouldn't be able to get their mail through to you. On the other hand, individually who want to send you one mail (and hopefully then get onto your whitelist) would have no problem with the cost of generating a hashcash token for you.
One problem with the scheme as proposed is that you need to keep a list of all hashcash tokens that you have received so that a spammer cannot generate just one and use it over and over again.
My idea is to overcome that problem by making hashcash tokens safely reusable.
I'm a great fan of EMACS. I use it every day for reading mail, for code development, and for just about everything involving text files. But I'm really hoping for something better to come along.
The problem is that while EMACS does have a reasonably good mail reader (VM, I use it constantly) and a very useful IDE bits and pieces and even a web browser, none of these applications are really great.
I think the reason for this is that it is really hard to write applications for EMACS.
I've taken the plunge and made aether my home page.
This required a few modifications to aether so that it could appear as though aether controls the whole name space, but so that pre-existing links still work. You can find the patch I used at , either in the applied directory if it is still applied to my source, or in the included directory if it has been included unstream.
I hope to eventually move all the content which sensibly can be moved into aether across into aether. Until then, my original home page is still available.
With my Email administrator hat on, I have been looking at SPF lately.
SPF stands for Sender Policy Framework and is a mechanism whereby the owner of a domain can advertise that domain's policy on how it sends mail.
When an MTA recieved mail claiming to be from a particular domain, it can queries that domains policy and then make a determination on how likely it is that the from address is authentic. This information can then be used as input to a local policy on dealing with junk mail.