Subject: Re: FVWM: Proposal on modules/languages

From: [email-masked]
Date: Tue, 5 May 1998 8:34:34 +0100

Manfred Bartz <[email-masked]> writes:

> [email-masked] writes:
> 
> > I would much prefer to use an existing configuration language if at
> > all possible. Inventing a new language usually means the product will
> > be delayed quite a bit longer than necessary. And why not take that
> > complication out of the project?
> 
> Absolutely.  There are too many configuration languages as it stands.
> Creating a new one would be madness.
> 
> So, maybe we should re-focus on which language would be most suitable.
> 
> Scheme is already being implemented in the fvwm-derived ``scwm''.
> Since we don't want to re-invent any wheels, anybody wanting scheme
> should look at contributing to scwm. 
> 
> Questions: 
> 
> 1. What would we want to do with the configuration language?

My configuration of fvwm consists of a number of M4 scripts that
generates menus and toolbars, and setup icons, color schemes and the
like (anybody familiar with TheNextStep should recognize this). There
are a number of problems with this concept, the most serious (for me)
being the fact that the translation of the M4 files into a new .fvwmrc
file takes 20-30 seconds on a fast machine. Also, any addition of a
new program or anything similar can take some time to configure.

If only the m4 preprocessor was faster or my configuration was
interpreted directly by fvwm, then my setup would be very usefull
indeed. But, as it is, it's a pain!

So I woul like a configuration language with full access to the file
system, so I can test for various executables and read various
configuration files (e.g. color schemes).

I would also like to make an interactive configuration tool for fvwm,
much like the tools seen for Windows95 and other end-user focused
operating systems. (No flames please!!!! Much as I dislike the central
concepts of Window95, I must admit that Linux, and for the matter most
other UNIX look-alikes, are hopeless, when it comes to configuration.)
Making new menus, adding programs, setting the overall look-n-feel,
setting speaker volume, etc. should be easy as pie! All this could be
handled in a module, but then that module should have complete access
to the state of fvwm. IFAIK there are some limits on what you can do
through the existing fvwm module interface. If one could send
ambitrary scripts to be evaluated by the fvwm core, then we would have
complete freedom to divide functionality between the fvwm core and a
module.

If the configuration language of choice has access to X11 in a manner
similar to the TK package (Tcl/tk, perl/tk, ...), then that would open
a completely new balliwagon of possibilities!!! Just imagine the type
of interaction one could have in the menus. Toolbars would also be a
natual part of the core just like menus. etc. etc.

> 2. How often would we use it.

More or less, all the time. Not directly, normally, but through the
different tools.

> 3. What kind of language would people find most approachable? 
>    (Especially if it's used only occasionally?)

IMHO the primary goals for a new configuration language are:

- we should *NOT* invent a new language, but an exiting (actively)
supported language (I know that is the title for this thread, but it
can not be said often enough :-)).

- the language should have all the modern programming constructs like
lexical variables, conditions, while, for, procedures and
packages/modules/namespaces.

- complete access to the file system (test, read and write).

- an easy API for add-on functionality (TCL is a nice example,
whereas in perl it is somewhat harder to add new functionality)

- nice-to-have are closures and threads (though especially the later
can limit the number of platforms, for which the language is avaiable,
I suppose).

- if possible the language should be compiled to byte-code (or
something similar) when read by the interpreter, both for speed and to
perform complete syntax and semantics checks. Also if possible, the
byte-code should be savable for fast re-read of the configuration.

- the language should havee a basic widget set ß la tk (as in Tcl/tk)
either in the base language or (better) and an extention.

> Comments?  Other questions to ask?

What are the possible candidates??

My current list consists of TCL and perl, both of which are actively
supported by a lot of people.

TCL
---

pro's:

- very small kernel
- TCL/tk exists
- well documented in several books

con's:

- only one complex datatype
- no complete syntax and semantics checks at load time
- many people dislike the somewhat peculiar syntax
- no byte-code compiler.

Perl
----

pro's:

- multi-threaded
- perl/tk
- complete operating system access
- well documented in several books

con's:

- no byte-code compiler (is this true anymore?).
- complex add-on API

/tonny

--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Bob Woodside <[email-masked]>
Date: Tue, 05 May 1998 06:19:09 -0400 (EDT)

> - no byte-code compiler.

        No longer true, as of 8.0

---

From: Brady Montz <[email-masked]>
Date: 05 May 1998 09:37:57 -0700

> What are the possible candidates??

Python, and guile too. 

> - no byte-code compiler (is this true anymore?).

Python
------
Pros:
- multi-threaded
- tk
- complete operating system access
- tons of supplied classes for things like gdbm
- very active group of users (they've even written a complete web browser),
  with some good books.
- very straightforward to embed and extend
- has always been backward compatable so far
- nice type system (you've always been able to make multidimensional arrays
  :-)) 
- byte code compiler
- supports multiple namespaces (a key pro for me, as you can pass the eval()
  function a dictionary variable to use as the namespace for the evalurated
  string)
- nice type system

cons:
- hasn't been the fastest language, although is is improving, probably as fast 
  as tcl now.
- tk support isn't as good as in tcl, although probably about as good as 
  with perl

-- 
 Brady Montz
 [email-masked]

---

From: "Jos\i Manuel Sousa Pereira" <[email-masked]>
Date: Wed, 6 May 1998 03:26:41 +0100 (WEST)

>> What are the possible candidates??

  BM> Python, and guile too.

(big snip)

  BM> cons: - hasn't been the fastest language, although is is improving,
  BM> probably as fast as tcl now.

What! Has tcl improved so much recently? I have to give 8.0 a try...
;-)

More seriously:
I'd add
cons: the interpreter bloats fvwm considerably.

This applies to all other proposed interpreters. Tcl seems the least bad.
But there _are_ some lean implementations for some languages, such as Forth
(several), Scheme (Elk?), Slang?

It does not have to be _best_ language, just a good enough compromise between
features and size...