Lambda the Ultimate

Also, I don't believe this really qualifies as an LtU topic...

Seconded. (Unless I am missing something)

I didn't realize there was qualification criteria. My fault. I thought this site was for general stuff related to programming langauges. Is it more specific than that?

Please review the FAQ and policies document, especially the sections on purpose and policy enforcement.

If you think your question is relevant for LtU, it would be a good idea to attempt to explain why.

Well I read over the policies and while I realize my question isn't about programming language theory, I think it still has relevance because writing an interpreter for any programming language that can use object files requires some way of executing object files at runtime.

Beyond that, this is a place of learning about programming-language-related topics in general. As the FAQ says "we allow ourselves moderate forays to bordering issues like programmability and language in general."

Is there a place on the internet with more intelligent and knowlegable people who know about programming than Lambda the Ultimate? If so let me know and I'll go ask this question there instead.

Well I read over the policies and while I realize my question isn't about programming language theory,...

I think it still has relevance because writing an interpreter for any programming language that can use object files requires some way of executing object files at runtime.

Is there a place on the internet with more intelligent and knowlegable people who know about programming than Lambda the Ultimate? If so let me know and I'll go ask this question there instead.

Thanks Chris, for your detailed response. I am not a first time poster, but I am new. In general, I find the backlash against "off-topic" posts on these types of sites to be ridiculous and childish. If I posted a topic about pokemon, feel free to slap me. But if I posed an at least semi-related, good faith topic on a rarely (if ever) discussed issue - I do not expect or appreciate the backlash. Not to say you are lashing out chris, your post was very helpful. But a community doesn't grow by allocating a significant amount of its time biting newbies.

I hope my first statement didn't come off as 'biting the newbie', but I must say I'm tempted to gnash and gnaw a little now, after being indirectly called 'ridiculous and childish'.

Static libraries and the explicit resolution thereof (as opposed to implicit dependence on a runtime-provided linker) is a topic of potential interest to many LtU readers. That isn't the problem.

The problem is in the first two words: "How to". LtU isn't a How To site. 'How do I load/interpret bitmap file headers?' or 'Where do I look in an MP3 file for the metadata?' and even 'How do I load/interpret Lisp files at runtime?' are only tangential to concerns of language and language theory.

frencheneesz, this is enough. Please review the site policies which served a very large community for quite a few years, and which were thought over carefully. Your posts will be moderated until further notice.

I direct your attention to the phrases beginning "it is firmly suggested..." in the FAQ. Please also change your account information per the LtU policies regarding personal names or identifying information. Your attempt at a sincere question (as you did in your next post) also raises a feeling of disingenuousness given your tone in the current thread.

P.S

David, your original reply was a helpful answer in my opinion, both substantively and as regard what's appropriate for LtU. Thanks.

The dirty secret of Programming Language implementations is that they are just programs - PL programmers make programs that other programmers use. A PL implementation is a program that takes input, applies some function to it that produces some output. This process of I/O translation can be formally described Operationally, Axiomatically or Denotationally.

The other dirty secret is that no matter how high level a PL strives to be, buried in the implementation is probably some C code (or worse Assembly). Even those compilers that are self compiling (meta-circular) have to start with a least a minimal amount of hardware addressing, though some later manage to kick the ladder away.

From a PL standpoint, the act of digesting something like text and outputting compiled code requires that the PL (or a foreign interface to another lower level PL like C) be able to interface to the hardware - usually via memory mapped I/O. Once you have access to hardware resources (memory, files, etc...), then you are free to read any programs, lex, parse, evaluate, compile, and then output the results. There are a plethora of algorithms and tools which are available to perform such mundane chores. There are also a lot of official as well as arbitrary standards about linking files together to create executables.

But by using the terminology of linking and static in the question is a dead giveaway that you are interested in a particular type of implementation. For example, Java compiled code does not statically link - it all compiles to an encoded class file (my Java Class File Disassembler comes to mind. Other compilers do systematic global optimization, so they just lump it all together.

The bottom line for your question is that you could look at a multitude of PLs to see how they were implemented. But LtU would probably only be interested in the question of implementation of a particular PL if there were some reason that the implementation strategy had some sort of impact on the resulting language.

Keep in mind that there is a corollary to your statement. Everything from Haskell to C to Assembly to Machine Code is a program written in a programming language, though not always one we'd favor writing code in directly.

I wouldn't mind looking at static library formats from a 'file formats are languages too' perspective. The fact that these languages are often used as the output when implementing other languages is somewhat moot. C has properties all on its own whether or not one is compiling Haskell to C. Object file formats have properties worth examining whether or not one is compiling C to object files.

Further, 'linking and static' are issues even in 'live' programming environments and language design (as you might see in Smalltalk or Mozart) because one is often dealing with 'immutable' text-as-code and other values. My perspective and understanding of 'language' tends to encompass the entire Operating System. Runtime executable formats with relocatable code sections are languages that aim to achieve useful properties for reading by the CPU and writing by the dynamic linker and manipulation by the Garbage Collector.

So I don't have any objection to the subject of static libraries.

The only objection I have is to the 'how to'. The task of implementation is outside the scope of LtU.

The OP is really asking what data structures are used in the processing (algorithms) and output (file formats) used by PL implementations. My limited understanding of PL implementations leaves me with the feeling that they are faced with the same sort of software engineering crisis that the rest of the programmer community faces. Which probably means that the data structures are antiquated with much rot and not ideally suited for the task at hand. But like any software effort they have to get the job done under less than ideal circumstances.

I would also note that what is considered to be a relevant to the discussion of PLs can be somewhat time sensitive. Back when PLs were first being developed, it was hard to separate the discussion of the environment used by the PL with the PL itself - and to some extent that still holds - witness the conflation of Java the Language with Java the API with Java the Virtual Machine.

Anyhow, I don't disagree with your assessment about why the original question might be off-topic. But I figured actually discussing the relationship (or lack thereof) between PLs and their implementations beat simply engaging in a yes-no contradiction sort of argument. My problem with the original question is that it is expressed in a form that can not be objectively answered. Every PL implementation uses different techniques to solve the problem. The better answer to it would be to say that the OP should pick some languages they are familiar or interested in, and see if they are documented in those projects.

Chris: Neither of the weblogs you mention shows up in Google, so if these are references to real, existing things, could you provide links?

...to direct all such queries to the BitC mailing list.

[And since this thread is the sole google entry for "The Language Programming Weblog", you might expect a fair amount of traffic]. :-)

BitC certainly needs to solve the underlying problem, and we do use our mailing list for design discussions, so the question would be perfectly acceptable on the BitC list. The only caveat is that we would tackle it as a "how to do this in BitC" discussion, and leave it to frencheneesz to adapt/apply it to his work. If frencheneesz wishes to take it up there, he is certainly welcome to subscribe and ask.

Ehud's comments and the policy document actually led me to some concern about my own postings, since some of them have leaned heavily in the pragmatics direction. I hope that they have been justified on grounds of novelty. I have tried to comply with what I took to be the spirit of the policy, but I am not convinced that I have always succeeded.

That said, there is a real need for a Wiki somewhere that collects implementation wisdom. Too much of that knowledge is not documented outside of its implementing code, with the consequence that language experimenters spend far too much time re-inventing it. a "PL Runtime HowTo" wiki seems like a potentially useful thing. Does one already exist?

As most regular members know we are not too strict in applying the policy. If something raises concerns someone is bound to mention it, and if the poster is able to explain why the topic is of interest, the discussion usually goes on. If no one complained, it means that the posts were deemed ok by the community.