Re: Some more debconf queries
Rob Browning wrote:
>
> Eray Ozkural <erayo@cs.bilkent.edu.tr> writes:
>
> > Well, using scheme/lisp expressions is daunting. The MacOS X people
> > are using XML for the task but IMHO, that's even crazier.
>
> Well, personally, I think that these dayas xml is the only current
> viable (though much more complex) alternative to something like lisp
> forms if you want something flexible since it's there, and I've heard
> the parsers are readily available. AFAIK it's sill another wheel
> re-invention, but it's one of those buzz-words these days.
>
Parsers... The XML standard does specify some flexibility for
the parsers [... shall not stop processing.. when...] but still
it's a documentation language. And, *ahem* scheme is just another
LISP. And with LISP, you get to destroy some of the design objectives
of a good programming language, like readability and writability.
On the other hand, it's good for pedagogical purposes. It's a great
way to tell CS students what recursion is. Just like Java is good
to tell students how nice object oriented programming is. How
many of your applications are written in Scheme? Heh heh, this is
my argument against Java, but it applies to LISP and variants as well.
Hey, there's a whole world of emacs here, but isn't it dying? :>
> > * class based language
>
> But you're now writing another language, another syntax, and another
> parser, and it's bound to be more complex than scheme. Note that here
> when I say parsing, I'm talking about the mechanical process of
> getting what you wrote from disk into a set of data structures you can
> manipulate from a programming language. That does not, and should not
> AFAIC, have *anything* to do with the semantic content of those forms.
> That's for a higher level process to analyze.
Well sure, in order to parse scheme you don't need much stuff.
But remember that the syntax of a language is not decoupled from
its semantics. On the contrary, many linguists would argue for
compositional semantics. Scheme feels good for programmers, because
it has strong compositional semantics. That is, the leap from
syntax to semantics is small. The syntax of the language elegantly
implies the meaning of expressions therein.
And talking about parsers, I don't feel like providing an LR(1) grammar
in an awkward bison file, and then trying to hack around it a
semantic analyzer written in C. That's so 70's, I get the chills
as if I'm reading dragon's old book.
Coming up with another language may feel very evil, but isn't Perl
so? Why has tons of Perl code amassed on my potato box?
>
> My observation has been that "rolling your own" language is trickier
> than most people realize going in. As the complexity of your spec
> grows, without automated help, it can be really difficult to make sure
> you don't specify a mathematically unparsable, or at least very hard
> to parse, language.
Mathematically unparsable? What do you mean? That is, I don't
intend to put forward an ambiguous language :) Though almost all
languages you can come up will be CSL; that's why you need a good
grammar formalism, and a good parser. A practical way would be
to write it with bison/c++. But it'd be difficult to get things right.
Simply because a class based language has a somewhat complicated
semantics. And no, I can see a Python or Perl wizard suggesting,
why don't we do it in our lovely interpreted language? Well, they're
not declarative. A configuration language has to be declarative.
And for declarative languages, could we start with Prolog? And hey,
LISP or scheme are somewhat declarative!! But believe me that
they will never work, because I think they will be far from readable.
The catch here is that the config file should be editable.
How do you get that? I'd opt for some of the quite innovative
literal syntax in some recent languages, and wrap around
them a very clean class semantics. The tricky part is "How are
these config files and application specific config files kept in
sync?". That's another issue, and not a trivial one. On that, I don't
think an XML approach will be fully satisfactory. The configuration
programmer must have a way to define the syntax and semantics
of the target language, at least partially.
>
> It's hard to beat scheme's simple rules (this isn't quite complete,
> but captures nearly all the language):
>
> 1) Everything is a list or an item.
> 2) Every item is a list or one of a few well-specified types:
> char, string, number, symbol, etc.
> 3) A list is either empty () or it contains items (a b c ...)
>
> (this leaves off vectors, but they're conceptually just another type
> like lists)
>
Good enough, I remember having written a LISP parser in LISP, so
LISP-like languages have quite easy syntax...
> That's it. Deciding what you're "config language" should look like is
> then just a matter of deciding what list structures are "legal" and
> writing a fairly trivial recursive descent function to traverse them.
> If you want to allow fancy inheritance, etc for your semantic
> structures, then fine:
>
Yeah, but recursive descent parsers look very old fashioned to me.
A PDA roaming down the memory.
> (some-config-option
> (parent-class some-class)
> (config-file "/etc/myprog/foo.conf"))
>
> And reading in your config file is accomplished with nothing more than
> a series of "read" calls.
I'd like to point out that class semantics have been
traditionally awkward in LISP-like languages. I read a whole
book on CLOS, and wrote wrong syntax in a very easy exam, and I
don't believe that would recur if it were with a more native
class based language.
>
> Anyway, I didn't mean to be suggesting this as anything that'll ever
> actually happen, I'm just a little amazed that people are willing to
> spend as much time on doing things the hard way as they seem to be.
>
> I'll shut up now.
>
Yeah, but I like talking about toy/experimental languages of any sort.
You know, if everyone thought like that there would be exactly
no new programming languages on earth. We would be stuck with assembly,
and a lot of macros. Now the situation is a bit different, do you
think that C++/Perl/Python will be viable ten years later?
Keep cool,
PS: Oh, FORTRAN might be viable still. I don't want to comment
on it. Still, the HPF is the most complicated language ever!!
--
++++-+++-+++-++-++-++--+---+----+----- --- -- - -
+ Eray "eXa" Ozkural . . . . . .
+ CS, Bilkent University, Ankara ^ . o . .
| mail: erayo@cs.bilkent.edu.tr . ^ . .
Reply to: