Re: Tips for features

[Gary V. Vaughan]

On Wed, Oct 03, 2001 at 11:00:23AM +0200, David Sterba wrote:
> Hi,


Hi Dave!

If you are especially keen one any of these, there are only a few that
couldn't be done with the new loadable module API.  Why not try it and
submit some modules.  We can incorporate the ones we like into the
core...

> Macros
> ------
> * macro aliasing

What do you mean by this?  How about:

define(`aliasname', defn(`target'))

> * variable support in eval; setvar(x,10)eval(x+1)

define(`x', 10)eval(x + 1)

> * macro: set maximum level of inclusion

For loop detection?

> * macro: set parameter evaluation: yes/no
> * macro: set type of param eval: before/after parsing

I see what you are getting at, but I am finding it hard to imagine an
example where having these features is a win over what we have
already.  It is "just" a matter of quoting carefully arfter all.

> * macro: repeat string; repstr(20,*)

Could be done in m4.  But a module would be faster.

> * macro: insert char from table; chtab(ascii,10), chtab(utf-8,0x333)

A worthy module.

> * macro: date/time through strftime

We already have this in one of the test modules in CVS IIRC.

> * macro: read/write environment

Reading is implemented by converting the environment into text macros.
Why would writing the environment be useful?

> * macro: eval - implicit multiplication before `(', variable, unary +/-,
>          not necessary to write right closing `)' (if well quoted)

Ai-ya!  Are you sure?  Unary +/- should be easy.

> * macro: label/goto to simplify loops

That would be tough.  And it seems to go against the way everything
else works, so I wouldn't be keen on this.

> * macro: split string by given delimiter and return nth field (internal
>          implementation of array)

That would be cool.  Easy to do as a module too.

> Other
> -----
> 
> Strings:
> * add to every string sizeof(int) header which will contain the data length
>   write macros for handling this strings

This would be a necessary part of 8 bit cleanliness I think.

> * 32bit length + optional width of char cell: char, wchar_t, ...
> * multibyte support (internally in wchar_t)

These would need to be implemented in the core, and I would love to
receive patches ;-)

> Speedup obstacks:
> * check obstack room and grow with obstack_*_fast
> * disadvantage: cannot use obstack_1grow due to multibyte buffers

Seems like a good idea.  Patches would be good :-)

> Guile support for extending

We have perl, though the perl module API is in a static library, so
building the perleval module is less portable than it should be.

I tried very hard to work out a guile module to implement a loadable
guileeval builtin, but guile will not work (as of 1.4 when I last
looked anyhow) unless it has control of the main loop, which I really
don't want to do.  If you come up with a way to implement this
*without* slowing down the current implementation, and without a
forced developer dependency on guile, I would again be happy to
evaluate patches...

Cheers,
        Gary.
--
  ())_. Gary V. Vaughan     gary@(oranda.demon.co.uk|gnu.org)
  ( '/  Research Scientist  http://www.oranda.demon.co.uk       ,_())____
  / )=  GNU Hacker          http://www.gnu.org/software/libtool  \'      `&
`(_~)_  Tech' Author        http://sources.redhat.com/autobook   =`---d__/