Marc Olschok <nobody@[EMAIL PROTECTED]
> writes:
> Aleksej Saushev <asau@[EMAIL PROTECTED]
> wrote:
>> Marc Olschok <nobody@[EMAIL PROTECTED]
> writes:
>>
>> > Aleksej Saushev <asau@[EMAIL PROTECTED]
> wrote:
>> >> Bruce McFarling <agila61@[EMAIL PROTECTED]
> writes:
>> >>
>> >> > On Apr 30, 5:14 pm, Richard Owlett <rowl...@[EMAIL PROTECTED]
> wrote:
>> >> >> What do they have in common?
>> >> >> Someone else has compiled raw data. It's available in ASCII
format.
>> >> >> That requires me to parse it.
>> >> >> I doubt anyone would claim string handling as a Forth forte.
>> >> >
>> >> > However, parsing data in ASCII format *is* a Forth forte.
>> >>
>> >> But the world is not ASCII, and this brings Forth to failure.
>> >
>> > Perhaps the word "контексте" might be worth noting.
>>
>> I doubt it, even in the context of ASCII Forth isn't good at parsing,
>> regular language isn't a problem, but even for that language you have
>> to hardcode your parser, instead of reusing regular expressions.
>> (Even Delphi programmers do it!)
>
> Most likely a Forth programmer will happily hardcode a special purpose
> parser adapted to the structure of the data, in the same way as he
> would build a special solution adapted to some other problem.
In Forth land programmer does the job of lexer and parser.
How does your statement align with "1x" and other Forth buzzwords?
Hardcoding is called so, because it is _hard_ to code (among others,
it is hard to maintain too, if possible at all, which suits more
"write-only" attribute of Forth).
> I cannot speak from experience here because I do not have any serious
> parsing problems where code size is an issue (usually sed and awk are
> good enough for me).
And when your awk/sed scripts with sh glue code become too slow?
What will you do?
JFYI, one of Google Summer of Code projects this year is
rewriting a set of such sh+awk+sed in C.
>> When it comes to more complex grammars, I start being afraid,
>> that Forth BNF parsers are too unusable even for hardcore
>> Forth hacker. The famous one-screener is purely conceptual ("toy"),
>> I don't remember, if I have ever seen any example of its usage,
>> as for others, I don't remember sample code for it either.
>> To be successful in any field there should be documentation and
>> sample code, or at least the very little sing of code usage.
>> I don't observe any. I may be wrong here, since it's been quite
>> a long time since I checked, but I'm not optimistic.
>>
>> Maybe, if anyone could point to documentation and sample code
>> for BNF parser, I could try using it again, though I'm not that
>> optimistic.
>>
>> >> > Then add on top the lack of a de facto library management
standard,
>> >> > and on top of that the fact that for those who only need to do a
>> >> > specific, people with a distinct set of concrete string tasks can
>> >> > solve it from scratch with tools like those in TOOL2002. If that
is
>> >> > auxiliary to their main task, then once its solved, they may
rarely
>> >> > need to revisit it. So instead of investing the time and effort
into
>> >> > learning and importing a general purpose string handling toolkit
and
>> >> > than using 5% of it, they build a much simpler special purpose
string
>> >> > handling toolkit and use 100% of it.
>> >>
>> >> And thus reinventing the same wheel 100 times, instead of reusing
>> >> the library written once years ago.
>> >
>> > Well, what if it is another wheel each time?
>>
>> It is even worse. Dealing with a dozen of non-standard kinds of
>> screws is a nightmare, it causes only one and the single wish:
>> to cram all these screws up those engineers' asses.
>
> Who surely will be glad that it is only software.
>
> But I was actually thinking not just of different implementations
> of the same task (along different ways) but instead of implementation
> of different (but specialized) tasks. For this, using some already
> written general library might involve adapting it to the specific
> requirements. The programmer will then try to guess, if this is more
> work than writing a new implementation from scratch.
Have you ever tried to support a collection of the code?
Like that, that comes from various GNU and near-GNU sources.
Many sloppy programmers don't use libraries, they prefer shipping
their own versions. I.e. there're dozens of MD5 implementations,
hundreds of base-64 and UU encoding-decoding routines around.
Sometimes those developers just cut and paste the code.
Now what happens, if one innocent soul finds a bug in the
library of one project, especially if it is design bug.
This bug gets fixed in one or another projects, but stays in
others. Just like broken gene. From now on you can't be sure,
that that bug will never manifest itself.
Maybe the word "anti-pattern" is known to you. Once you find
anti-pattern in your code, and fix several its incarnations,
you become unsure, that you really have found and fixed all of
them, especially when you use archives and import others' code.
--
BECHA...
CKOPO CE3OH...
|
