Re: parser


"Jon Harrop" <jon@xxxxxxxxxxxxxxxxx> wrote in message
news:_YednQJTP6HSBUvVnZ2dnUVZ8gidnZ2d@xxxxxxxxx
cr88192 wrote:
"Jon Harrop" <jon@xxxxxxxxxxxxxxxxx> wrote in message
news:lqSdndI7kd7b1kvVnZ2dnUVZ8hidnZ2d@xxxxxxxxx
Surely you did not expect C++ to survive indefinitely?

as it so happens, my opinions match pretty well with the current
graphs...

Except that you thought C and C++ were thriving when, in fact, C has
bottomed out at 9% market share having been overtaken by two functional
languages and C++ is at 16%, already behind one functional language and
still falling by 3.75% every year.


now, where are you getting this exactly?...

what info I can find typically shows Java, C++, C, and C# as the top used
languages...


now, as it so happens, C++ is behind Java, but it has by no means gone
away, and by no means is Java some obscure language...

I'm glad you finally agree. :-)


where did it ever come off like I thought Java was obscure?...

if one remembers, I was strongly arguing against that 'Juha whatever'
person, who was claiming C++ as the 'one true language'. I don't hold this
position, but I still feel that both C and C++ are good languages to use for
actually writing stuff, in particular because of the positions they hold as
systems languages (it makes a very good amount of sense to write ones'
backend code in these languages, and then use alternatives, such as Java,
Python, or ECMAScript, more for frontend code or scripts, where these
languages don't exactly work so well in the backend).


now, Java is more like this phantom that is theoretically used heavily, that
it just so happens takes a minority position in terms of encountered
opensource projects and code (the ordering: C, C++, Java, and Python, Perl,
.... seems to be most common in opensource land from what I have seen).

now, of course, I would not use Java in the same way I would use C, because
it can't really do what I do in C. I have at times considered the
possibility of writing a Java-ByteCode interpreter, but have lacked
motivation, and though I could theoretically use GNUs JVM, this would make
the project be tied specifically to using GCC (and of course, not integrate
well with my existing framework).

however, with some recent stuff, implementing an interpreter (and maybe also
JIT) for JBC may make sense (will probably just use gcj for the compiler
though, and leverage GNU's classpath, but oh well...).

actually, I have a bit more incentive for loading JBC than for MSIL/CIL (I
had actually considered this before, but by investigating things came to the
opinion that the CLR would be a major PITA to implement, and MSIL would not
exactly be convinient...).

JBC would likely require much less in terms of effort to implement (granted
in part, some of the "heavy lifting" is done in the compiler frontend,
leaving the backend interpreter/JIT as a simpler piece of machinery).

some of the recent ideas in my case for better integrating my JS interpreter
with C land by extension will also work with a JBC interpreter (and, at
least, it should be much less work to integrate Java and C's typesystem than
it has been to integrate the dynamic typesystem and C land, which is,
arguably, only partial...).

I guess all of this is a potential advantage of a "decentralized" VM design.
everything is libraries, which just sort of use each other and are plugged
together in specified ways. all that is needed really to add new machinery
is make it talk to the existing machinery...


of course, I naturally suspect you would probably oppose Java as well,
claiming it to be some obscure/archaic/low-level language since, after
all, it sort of looks and behaves much like C++...

On the contrary, Java bundles a high-performance concurrent garbage
collector and an API specifically for run-time compilation in its stdlib,
both of which are tremendously productive in the context of parsers and
compilers.


and, ammusingly, I have written these features for C (ok, granted I have a
concurrent GC, and it is not necessarily "high performance", and in some
cases may stall other threads during a GC phase). these issues can hopefully
be improved eventually (well, that and me better improving the write
barrier, which I have discovered can cause occasional screw-ups...).


I would advocate C# over Java in this context though, because it is not
only
very popular but also provides more relevant features and tools in this
context.


but, as a major cost, C# has poor support on Linux at this point in time...


now, what I doubt, is your endless evangelizing for certain FP languages,
which are IMO unlikely to ever really grow much beyond niche usage...
and so, the likes of Java, C++, C, C#, JavaScript, ... continue to
dominate for the most part, whereas LISP/ML/... remain relatively
obscure.

Both C# and JavaScript have first-class closures, i.e. they are already
functional programming languages.


it depends I guess on how one defines "functional" (I would not have
otherwise considered JS and C# in this category myself).


in my case, I have a crude approach for making closures in C as well
(another one of those funky pieces of machinery, may involve some amounts of
machine code being generated at runtime and stored in heap-based "executable
objects"...).

the code theoretically also supports x86-64, but I have not really tested it
there...

on x86, a much more performant version of this mechanism could likely be
written, but oh well. the current machinery chains together several more
"general purpose" mechanisms (these actually being used for interfacing
between C land and the other VM machinery), although for the sake of
performance, at least on 32-bit x86, for making closures one could replace
all this by a trampoline, making them essentially not much more expensive
than a plain function call (the current approach involves several levels of
dynamically generated thunks, memory copying, and function calls...).

now, I can also note that GCC does tail-call optimization, but I will not go
on to claim that C is a functional language (even if I can implement much of
the machinery usually associated with such languages...).


the graphs seem to show this, and so it doesn't matter much.

The graphs show that two functional languages have already overtaken C in
terms of popularity. So obscurity-based arguments against using them are
no
longer valid.


JS and C# are not the type that most people advocate though, they are more
like traditional languages with a few useful features, and not the complete
abandonment of conventional syntax and analization of more "proper" FP
languages (such as Haskell, ...).

now, as it so happens, I like JS and C#, and would even endorse Scheme and
CL if I figured there was much of any real chance of people buying into
them...

I don't claim that FP ideas are not useful, only that more "proper" FP
languages, don't have much chance...


my advocacy is, after all, for "common" languages, and whether or not
this
is C, C++, Java, or anything else, is not that big of a deal...

The differences between C and C# are a huge deal in terms of productivity
in
this context. Look at parser combinators, for example:

http://blogs.msdn.com/lukeh/archive/2007/08/19/monadic-parser-combinators-using-c-3-0.aspx

That is hugely productive and essentially impossible to implement in C.


skimming over, the basic approach, however, is possible in C, and is not too
far removed from a recursive descent parser...

now what is so "impossible" in C?...
that you believe that C lacks the ability to build parsers as masses of tiny
pieces sharing and building bits and pieces of a parse tree?...

this is already how my parsers tend to work...

as noted, one just needs to write the right utility code, and everything
becomes much easier.
the main cost is that I currently lack more convinient ways to do token
processing and dispatch, but I have floated ideas for this as well (namely,
in replacing the buffer-filling-tokenizer approach with the use of
dynamically-typed code and utility functions).

however, much of my parser code is itself older (copy-and-specialize
approaches are common in my case), and so this is likely to be something for
later...


...
now, this in itself is another piece of evidence:
I have very rarely encountered Java apps in practice...

You probably use them without realising, e.g. when ordering goods over the
web.


yes, showing in a way, where they are used.

but, they are running on an Apache server somewhere, not in the code I so
often download and build...


--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u


.

Relevant Pages

  • Re: Basic inheritance question
    ... used 'this' in C++ and Java. ... but in Python it doesn't. ... you meant "in languages that has implicit instance reference available in methods"? ...
    (comp.lang.python)
  • Re: Looking for programming examples in any programming language
    ... in an in-page applet. ... do that for such a broad range of languages. ... But note even Java applets ... If you're going to separate the specific I/O environment from ...
    (comp.programming)
  • Re: OO compilers and efficiency
    ... > will be difficult for a compiler to do a good job of spotting when the OO ... "simpler" languages, ... I agree that Java ... (including adding lexical closures) ...
    (comp.programming)
  • Re: Basic inheritance question
    ... Old Java habits die slowly. ... No, seriously it isn't Java habits only, most other languages wouldn't ... That's not very far from what a Python method object does - ... reference to the current instance is to pass it as an argument to the ...
    (comp.lang.python)
  • Re: Is VB.NET dead?
    ... important in communication, it is understanding that writes good software. ... Of course, in the case of programming languages, the ... the similarity between the syntax of C# and Java ... is not one of "mere" punctuation. ...
    (microsoft.public.dotnet.general)