[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Scripting

From: Marco Gerards
Subject: Re: Scripting
Date: Mon, 14 Feb 2005 21:39:41 +0000
User-agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)

Hollis Blanchard <address@hidden> writes:

> On Feb 13, 2005, at 12:56 PM, Marco Gerards wrote:
>> Serbinenko Vladimir <address@hidden> writes:
>>>> What kind of parser is it?
>>> It's a direct parser with aritmetic subparser. Main parser is
>>> grub_bash_execute, arithmetic subparser is grub_bash_eval_arith.
>>> grub_bash_execute determinates the special cases (loops,conditions,
>>> functions,...) for other cases (commands,assignments, function
>>> calling)
>>> it calls grub_bash_split_tokens, grub_bash_expand_braces and
>>> grub_bash_expand_dollar
>>>>  I have never seen this in a top-down or bottom-up parser I have
>>>>  studied.
>>> I don't like to write the things reffering every time to algorithm.
>>> Genereally I take some ideas and I write myself, at my own.
>> What do you mean?
>> The problem is that I like proven concepts.  And when you use a
>> commonly known parser design many people will be able to understand
>> it.  To me this is REALLY important.  I wonder what other developers
>> think of that.
> I agree. Hand-written parsers are very hairy to implement, with nasty
> bugs and corner cases. Although I haven't studied the theory, I know
> that there are traditional parsing/lexing/whatever techniques that are
> well-understood.

Right.  But I would not have a problem with a hand written parser, as
long as I can understand it. :)

> In fact, there's a whole bunch of tools like flex and bison that we
> could use to avoid hand-written errors. Why don't we use those?

One thing that should be looked into before using flex and bison is
how much the binary will grow.  Another thing is how to integrate it
with the command line.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]