Should definitions of future computer languages incorporate IDE technologies?

[Stephen Tashi]

TL;DR Summary

Should definitions of future computer languages incorporate the basic functions of an IDE?

The definitions of currently popular computer languages assume only the technology of printing. For example, they provide syntax for printed expressions in one location that refer to printed expressions in other locations (e.g. "include" type syntax ). However, they don't assume that such expressions are links to anything, although an integrated development environment (IDE) may be able to make to treat expressions like links.

Writing code in languages like C++ or Java, seems (to me) to involve a lot of "boilerplate" text that is copied and pasted. Copying and pasting takes advantage of modern editing software. If it takes modern editing software to make it practical to code in a language, it also makes sense for the design specifications of future languages to assume more technology that merely the technology of printing. The definition of a future language could assume the basic functions of an IDE exist and define the language in terms of those functions.

 

[PeterDonis]

The definition of a future language could assume the basic functions of an IDE exist and define the language in terms of those functions.

I think this would be a serious mistake. IMO, a language that needs an IDE for a programmer to be productive in it is a language that has too much boilerplate to begin with.

The way to remove boilerplate from a language is just to remove boilerplate. You don't need an IDE for that. "Hello, world!" in Python is one line: print("Hello, world!"). No IDE required. (Python gives you one with IDLE, but you don't need it to program in Python; I've never used it.)

 

[Mark44]

You don't need an IDE for that. "Hello, world!" in Python is one line: print("Hello, world!"). No IDE required. (Python gives you one with IDLE, but you don't need it to program in Python; I've never used it.)

Nor have I.

 

[fresh_42]

You usually have the language first and the IDE on top of it. In reality the distinction is sometimes difficult. MS might insert their own libraries as default for Visual C++, and I know an IDE which has its own commands and syntax, where a C or C++ compiler is beneath.

 

[Mark44]

You usually have the language first and the IDE on top of it.

Right. The IDE isn't directly related to with the language -- it usually includes an editor, a debugger, and hooks to the compiler and linker, plus whatever other features it has.

In reality the distinction is sometimes difficult. MS might insert their own libraries as default for Visual C++,

In my opinion, the distinction between an IDE and a particular language is pretty clear. The tasks performed by an IDE are mostly unrelated to the particular language, possibly excepting editors that can check syntax.

MS might insert their own libraries as default for Visual C++,

Any C or C++ compiler is going to link in its own libraries, but that's really separate from the IDE. Most compilers are set up so you can run build scripts completely outside of the IDE.

 

[fresh_42]

In my opinion, the distinction between an IDE and a particular language is pretty clear. The tasks performed by an IDE are mostly unrelated to the particular language, possibly excepting editors that can check syntax.

This depends on the definitions. If an IDE has its own syntax and commands, but generates a C source code on the lower layers to create the executable program, none of which can be seen, is it a new language? Possibly. I still think that the distinction depends on the 'author'.

Any C or C++ compiler is going to link in its own libraries, but that's really separate from the IDE. Most compilers are set up so you can run build scripts completely outside of the IDE.

Right. But do you consider the library as part of the IDE or part of the language? Or neither? Depends on whether you are a purist or not. It is easy to tell at the university, but if you actually have to program software, you might consider the library as part of the IDE, since without you really have a problem. On the other hand, it is a software package which enhances the compiler.

 

[Mark44]

This depends on the definitions. If an IDE has its own syntax and commands, but generates a C source code on the lower layers to create the executable program, none of which can be seen, is it a new language? Possibly. I still think that the distinction depends on the 'author'.

I've not ever used an IDE that generates C (or C++) source code, and these include products from Borland and Microsoft, and another C compiler and a Fortran compiler whose names I don't remember. A C++ compiler can generate certain functions, like default constructors or destructors, but that's not something the IDE does.

Right. But do you consider the library as part of the IDE or part of the language? Or neither?

Neither. It's essentially just pre-written code that's been compiled into machine code that gets linked into a user-written program. A library adheres to the language, or else it wouldn't compile, but it's not part of the language.

 

[fresh_42]

I've not ever used an IDE that generates C (or C++) source code, and these include products from Borland and Microsoft, and another C compiler and a Fortran compiler whose names I don't remember. A C++ compiler can generate certain functions, like default constructors or destructors, but that's not something the IDE does.

https://www.windev.com/

I am not sure whether it is a compiler written in C or whether it generates C code beneath the surface (which I assume). In any case the IDE and the language cannot be clearly distinguished.

 

[Jarvis323]

I think it makes sense to design a language considering the capabilities of an IDE. I suppose that is like what we have already in essence, except maybe without a capital I, as our languages are based on the keyboard, and ascii characters, and so forth. We write programs with text, and there is assumed to be some kind of text editor and interpreter or compiler. That all is essentially a development environment.

Keyboards are pretty archaic and languages we use now are pretty much designed around their limitations. I've commonly wondered why we haven't designed a specialized version of the keyboard for programming specifically, since we could expand the sets of characters/symbols, and even include keys that can generate common compound statements or snippets. If the keyboard itself was different, then we would have designed the languages differently.

In general, we have not really experimented deeply how we might interface with an "editor" or ide, or what form the language of that interface is in. What do we use in a VR or AR environment?

You could build in accessibility translations, like voice to text, but customized and standardized for coding. And print to sound.
Maybe it could build in debugging functionalities, like adding breakpoints in the language itself.

Beyond the basic interface, you can include a standardized metalanguage to interact with the ide. Well this kind of exists, in C or C++ for example, people can use #pragma to interact with the IDE or preprocessor and compiler (e.g. to disable warnings for some code block, or compile the block of code in some special way), or interact with the preprocessor in other ways using macros, template meta programming, etc.

Boiler plate code can be dealt with by copying and pasting, but also by abstraction, modularity and the DRY principle. Languages already have built in capabilities to do that. These things often are so custom and the range of possibilities are so vast that it's perhaps sometimes better to do these things programmatically.

Sublime text as an example, is programmatically customizable so that you can design your own snippets, tab completion logic, trigger arbitrary preprocessing, etc. But I never like using snippets because they usually leave too many fill in the blanks, which interrupt the flow.

Another thing we have is regular expressions, which are useful in an IDE for find and replace etc. In some ide's you can also process the text with built in refactoring tools for smarter text replacement etc.

In general, we want to better manage complexity. The issue is that complexity is not a unitary thing. On the one hand you have something like Shannon entropy, how verbose the code needs to be, and on the other hand you have complexity in terms of the simplicity of organization and parameterization. And there is a tradeoff ; you make a simple but verbose and low level language and you don't need a long instruction manual (i.e. C, which doesn't takes long to learn) or you have complex features exposing more generalization and organizational complexity and you need a long instruction manual (i.e. C++, especially metaprogramming, and "concepts", which takes a long time and thousands of page of information to fully understand. So there is a Pareto optimization to do here when designing a language so that complexity is manageable and the code is understandable and maintainable.

The development environment is definitely a part of complexity management, so it makes sense to at least consider it when making these tradeoffs. For example, Java with Eclipse has the hotkey to show documentation feature, and I guess you can expect that all of the Java libraries have documentation. And there is some kind of standardization to the way it's documented so that users can easily navigate the documentation on demand. This is enormously helpful for ameliorating the burden of second kind of complexity (long instruction manual). You also have similar features in other IDEs and somewhat standard tools like doxygen. These are examples of embedded metalanguages that talk to the IDE I guess.

In general, it's these higher order IDE features which tend to make those higher level more abstracted and generic language features more usable.

I mentioned the DRY principle. Which means don't repeat yourself. E.g. try to eliminate redundancy and unnecessary verbosity. This is achieved through higher level features, for example with generics. But the issue is you commonly will have many slightly different versions if the same thing. So generalizing in programming language constructs can be complex (lots of degrees of freedoms for an abstract object, long instruction manual). But IDEs can he capable of detecting code reusability and exposing those degrees of freedom interactively in an easier way. Or different ways of doing it manually, through abstraction layers embedded in an ide could be possible. So I imagine new possibilities for dealing with DRYness if the language and the IDE talk to each other.

Multilevel languages, using DSLs at different layers, are also possible (e.g. like html css and javascript), except where some layer handles talking with the IDE specifically.

 

[Stephen Tashi]

You usually have the language first and the IDE on top of it.

Yes, however:

The title for the OP has been edited by a moderator to suggest the question concerns the current state of affairs. However, as the summary indicates, the topic of the OP is whether future languages should be designed only assuming the technology of printing - or should they be designed assuming more advanced technology, such as that provided by IDEs.

 

[fresh_42]

Yes, however:

The title for the OP has been edited by a moderator to suggest the question concerns the current state of affairs. However, as the summary indicates, the topic of the OP is whether future languages should be designed only assuming the technology of printing - or should they be designed assuming more advanced technology, such as that provided by IDEs.

This was my fault, since the original sentence with 'have' instead of 'do' wasn't a sentence, and the word future did not occur. Feel free to give me a clear alternative for the title and I will change it.

 

[berkeman]

Yes, however:

The title for the OP has been edited by a moderator to suggest the question concerns the current state of affairs. However, as the summary indicates, the topic of the OP is whether future languages should be designed only assuming the technology of printing - or should they be designed assuming more advanced technology, such as that provided by IDEs.

Apologies. I was not able to parse your original title 'Have computer language definitions dependent on an IDE?' so I tried to fix it up. As fresh says, we can help to fix your title so it says what you intended and is grammatically correct.

 

[Mark44]

I am not sure whether it is a compiler written in C or whether it generates C code beneath the surface (which I assume). In any case the IDE and the language cannot be clearly distinguished.

Looking at the link you gave, WinDev doesn't generate C code -- their WLangauge seems to be a combination of Visual Basic and SQL. The compiler is probably written in C#, based on mention of .NET assemblies in the PDF of the link.

WinDev seems to be something of a database manager, which in the context of programming languages is off in its own niche, separate from more general programming languages like C, C++, C#, Java, Fortran, and others. For these languages, there is a clear distinction between the language and whatever IDE happens to be in use with them.

 

[fresh_42]

Looking at the link you gave, WinDev doesn't generate C code -- their WLangauge seems to be a combination of Visual Basic and SQL. The compiler is probably written in C#, based on mention of .NET assemblies in the PDF of the link.

WinDev seems to be something of a database manager, which in the context of programming languages is off in its own niche, separate from more general programming languages like C, C++, C#, Java, Fortran, and others. For these languages, there is a clear distinction between the language and whatever IDE happens to be in use with them.

It started as a DB manager, but it is more. It is an IDE which allows you to build frontend and backend features at the same time. They have a test IDE for free. I think it is a perfect example of what the OP meant in post #10. If it were only a language, one could produce code in a simple text editor, change the extension and feed the compiler. This is not possible. If it was a pure IDE, then you should be able to use another one, which is also impossible. Hence it is a product where the criteria for distinction do not apply anymore. It is an all in one package, and the compiled code is created somewhere in the lower layers without having access to.

Here is an easy example:

EDT_text="Hello World!"
Wait(200,waitTimer)
EDT_text=""

This code is attached via the frontend design in the IDE to a click button. It inserts "Hello World!" into a text field for two seconds and empties the field again.

It is impossible to edit the code without the IDE, i.e. the location where the trigger for execution is defined, and the output is an exe file. And it is impossible to compile the code outside the IDE. So where does the compiler end and the IDE begins? I think the only distinction which can be made is, whether this is a proprietary software product, or whether it already matches what the OP had in mind.

 

[Stephen Tashi]

I was not able to parse your original title 'Have computer language definitions dependent on an IDE?'

I found it difficult to condense my thought into a short title, so I wrote "Have..." instead of the slightly clearer "Should we have...".

A better title is "Should definitions of future computer languages incorporate IDE technologies?"

 

[fresh_42]

I found it difficult to condense my thought into a short title, so I wrote "Have..." instead of the slightly clearer "Should we have...".

A better title is "Should definitions of future computer languages incorporate IDE technologies?"

How about:
"Should future computer languages incorporate IDE technologies?" Definition of is already confusing. And "should" versus "will" is another problematic wording. Should for whom and why?

 

[Stephen Tashi]

Definition of is already confusing.

Definition vs incorporation is an important distinction. Current computer languages define syntax for features that tell the linker or interpreter that processing a given document of computer code requires referencing other documents (e.g. "#include", and "import" type statements).

How much the definition of a language enforces a given behavior on linkers and interpreters varies from language to language. For example, how linkers search for related files can be configured in various ways - and the use of "symbolic links" in file systems offers more versatility and confusion.

I'd say the computer languages incorporate issues related to file systems if we count a particular linker or interpreter as part of the language, but I would not say that the definition of a (current) computer language completely specifies the behavior of a linker or interpreter.

 

[Mark44]

Definition vs incorporation is an important distinction. Current computer languages define syntax for features that tell the linker or interpreter that processing a given document of computer code requires referencing other documents (e.g. "#include", and "import" type statements).

"Translator" is a better choice than "interpreter," as the latter implies languages such as Python or others that translate and run one line at a time.
Processing #include files (in C or C++ programs) is not handled by the compiler per se. Instead, #include files and other preprocessor directives are handled by a separate component of the compiler called the preprocessor.
Import statements would be handled by a linker, not the translator.

How much the definition of a language enforces a given behavior on linkers and interpreters varies from language to language. For example, how linkers search for related files can be configured in various ways - and the use of "symbolic links" in file systems offers more versatility and confusion.

I don't believe how a language is defined has any relation to how a translator (compiler or interpreter) or linker work, other than the very minor detail of where to look for #include files or libraries that are imported. This is pretty much unrelated to how the language is defined.

I'm not sure what you're talking about with your mention of symbolic links. The compiler sets up a symbol table that lists the names and memory locations or offsets within memory. The linker (AKA link editor) uses the symbol table to "fix up" the references in the code to items in the symbol table for identifiers such as printf or other library functions.

I'd say the computer languages incorporate issues related to file systems if we count a particular linker or interpreter as part of the language,

But we don't count these tools as part of the language any more than we would count a profiler of spell checker as part of the language.

but I would not say that the definition of a (current) computer language completely specifies the behavior of a linker or interpreter.

Right. And I would add that the linker isn't involved at all. Of course, the compiler has to be built with "understanding" of the particular language, but the linker just brings in library code to the right places and carries out some other housekeeping details for the type of binary that is being built; i.e., an executable (.exe), a static library (.lib), or a dynamic library (.dll).

 

[Stephen Tashi]

I'm not sure what you're talking about with your mention of symbolic links.

In terms of Linux, the command "ln -s"

 

[Mark44]

In terms of Linux, the command "ln -s"

But this has nothing to do with compilers and linkers. This is an operating system command. What does this have to do with programming languages?

 

[Stephen Tashi]

But this has nothing to do with compilers and linkers. This is an operating system command. What does this have to do with programming languages?

Compilers and linkers try to navigate file systems. Anything that affects the structure of file systems can affect them.

 

[Mark44]

Compilers and linkers try to navigate file systems. Anything that affects the structure of file systems can affect them.

But so what? I still don't see how any of that is relevant to the programming language itself.

 

[Jarvis323]

I'm not sure what is the definition of definition in this context. A language has a syntax, a grammar, and semantics. I'm not sure if it makes sense to consider an IDE in these categories.

But there may also be a standard, which I think is more broad. I think the OP's ideas are more relevant to this aspect of the language.

The standard includes constraints that the vender, which implements the language, need to adhere to in order to meet the standard. In general, these constraints and required features make it possible for the language to be cross platform. If a person writes standard code, then their code should work correctly no matter which standard conforming implementation is used.

In general, the standard may have something to say about different parts of the toolchain, including a preprocessor, compiler, or linker. Sometimes there are even third party standards on top of the main standard, such as OpenMP, which most vendors may also try to comply with.

I think it's reasonable (depending on context) for a standard (the standard or a third party standard) to make rules and constraints that IDEs need to conform to. I can understand why many coders wouldn't like the sound of it, but I can imagine some arguments to be made about how consistency across IDEs could be useful.

 

[pbuk]

I can think of a few examples where IDEs have been built around existing languages that have then developed such that they could be considered as an inseparable whole:

• Delphi (previously Turbo Pascal, now disappeared*) - Pascal
• C# - C
• Android SDK - Java/Kotlin
• Cocoa - Objective C/Swift

The last two provide interesting examples where Android SDK/Cocoa started out based on existing languages (Java/Objective C) and then new languages were developed specifically for these platforms (Kotlin/Swift). This is perhaps closest to what the OP had in mind, however in each case these frameworks/SDKs (software development kits) go beyond simple IDEs and are tied to particular hardware and GUI implementations.

I wonder @Stephen Tashi what "basic functions of an IDE" do you think would be useful to include in the specification of a computer language?

* Edit - I didn't realize Delphi is still around, see https://www.embarcadero.com/products

 

[fresh_42]

I don't see the difference between "definitions of future computer languages incorporate IDE technologies" and what is simply a proprietary all-in-one system.

 

[Stephen Tashi]

I wonder @Stephen Tashi what "basic functions of an IDE" do you think would be useful to include in the specification of a computer language?

In the model of a language definition as a specification for a printed document, there are daring ideas like expanded character sets and color printing. Thinking of documents as electronic, there are features like HTML.

IDE's offer various techniques for debugging. The current computer languages that I know define ways to insert debug code and comment it out or insert it using macros that can be disabled. In a printed document this is distracting clutter. In an electronic document, we can imagine the document having various versions and having one version that makes debug code invisible.

The definitions of current computer laguages already intrude on issues of file systems For example, in Java, there is the rule that a public class must be put in file whose name matches the class name. In C, there is the distinction between "#include < name.h>" versus "#include "name.h"". I'd prefer to have all the filesystem issues handled in some systematic way - perhaps a computer language needs a sub-language just to handle file system issues. We could even have two different languages for handling computations that employ the same sub-language for handling file system issues.

One way to look at the situation is this: A language must be designed so it can be implemented by current technology to do certain computations. One step in this implementation is compiling or interpreting the program. Hence file systems (or more abstractly, information retrieval systems) must be navigated. If there is a utility in abstracting the notion of computations then there should be a utility in having a language that abstracts the notion of information retrieval.

 

[Stephen Tashi]

I don't see the difference between "definitions of future computer languages incorporate IDE technologies" and what is simply a proprietary all-in-one system.

It's similar to the difference between a computer language and particular compiler for that language. Computer languages are abstractions of concepts of computation. There can be abstractions of the functions of IDEs that do not define a particular implementation of those abstractions.

 

[fresh_42]

It's similar to the difference between a computer language and particular compiler for that language. Computer languages are abstractions of concepts of computation. There can be abstractions of the functions of IDEs that do not define a particular implementation of those abstractions.

I have no idea what that means. Your first sentence is a comparison I cannot follow, since you compare code and software with what you call definition and incorporation, which still leaves the connection between the latter undefined. Your second sentence is wrong, as computer languages are no abstractions, they are commands how to move bits. And your third sentence is as foggy as the entire discussion here is. What is an abstraction of a function? There are groups of functions, but no abstractions. You explain one undefined term by yet other undefined terms. That leads nowhere. I changed the title as you wished, but it seems it is still cryptic, which is what I told you beforehand.

Either you provide some examples of what you meant, or you define the terms you use in an unambiguous way, maybe similar to what Chomsky did.

 

[Stephen Tashi]

Your second sentence is wrong, as computer languages are no abstractions, they are commands how to move bits.

I disagree. How bits are moved is determined by particular compilers. Machine languages determine how bits are moved. Higher level languages do not.

And your third sentence is as foggy as the entire discussion here is. What is an abstraction of a function?

Surely the technique of abstraction that is used to apply mathematics to various exotic fields of study can be applied to something as mundane as IDE's!

As a simple example, particular IDE's display particular types of computer language statements in particular colors. A language definition could state that the particular type of statements called (abstractly ) "debug statements", are to be displayed in a particular abstract color "Blue-13". The definition could specify that two versions of a code document exist. One version does not implement the debug statements.

 

[pbuk]

Your second sentence is wrong, as computer languages are no abstractions, they are commands how to move bits.

No, I don't agree with this. Implementations of computer languages are commands how to store and process bits, not the languages themselves. Almost all languages can be wholly defined using abstractions such as Extended Backus-Knaur Form which are entirely free of implementation context.

As a simple example, particular IDE's display particular types of computer language statements in particular colors.

But the colours can usually changed to suit individual user preference, or to improve usability for those with limited colour perception.

A language definition could state that the particular type of statements called (abstractly ) "debug statements", are to be displayed in a particular abstract color "Blue-13".

What advantage would there be in fixing this in the language definition? What about the loss of usability for people that can't easily distinguish Blue-13?

The definition could specify that two versions of a code document exist. One version does not implement the debug statements.

How do you keep the two versions consistent? What would be the advantage over implementing a 'Hide debug code' option in an IDE if you really wanted one?

 

[Stephen Tashi]

What advantage would there be in fixing this in the language definition? What about the loss of usability for people that can't easily distinguish Blue-13?

I use "Blue-13" as a abstraction of a color, not a particular color. A particular IDE could use a red color for "Blue-13". The definition of an abstract color implies that when Bob writes code in an IDE where he prefers "Blue-13" to be blue, then Alice can examine the code in her preferred IDE and have it be her preferred color for debug code.

How do you keep the two versions consistent? What would be the advantage over implementing a 'Hide debug code' option in an IDE if you really wanted one?

There would have to be definition of what "debug code" is before any IDE could implement hiding it. A definition of debug code as an aspect of a language would mean that debug code written on one IDE would be treated as debug code on another IDE.

How to keep two versions consistent is, as the saying goes, a topic for further research. In actuality, the two versions (with debug and without) are not consistent if we interpret "consistent" to mean identical. So what's a good computer science type definition for "consistent"? One thought is that the inclusion or non-inclusion of the debug code in a function or class should not affect the values of any variables external to that function or class.

If I'm editing the non-debug version of a file, is there technology that can warn me if I'm creating an inconsistency? Or perhaps I want to "disable" the debug version until I have time to fix it.

 

[fresh_42]

No, I don't agree with this. Implementations of computer languages are commands how to store and process bits, not the languages themselves.

I think this is nitpicking. The language is what enables humans to tell the compiler how the machine commands have to be set up in the compiled file such that bits can be moved, since this is the ultimative goal. The language is just the first layer. Whether we start counting there or at the implementation or the final executable code is playing in the sandbox. It is not different from machine codes, only a few conveniences above that level.

Computer languages are by no means an abstraction of calculations. TM are an abstraction, not C#.

And none of it - regardless where you draw your personal line - has anything to do with an IDE. Calling it incorporate definition is gibberish.

 

[pbuk]

In the model of a language definition as a specification for a printed document, there are daring ideas like expanded character sets

Most languages in current use already implement handling of expanded character sets, either by default as part of the specification of the native string type (e.g. Java, JavaScript, Python 3) or through libraries (e.g. ICU for C++). This has nothing to do with the IDE though.

Or do you mean expanded character sets in source code for e.g. variable names? This is possible in a number of languages but is a very bad idea and will get you sacked/result in rejection from an open source project.

and color printing.

What has this got to do with an IDE, or is this about syntax highlighting again?

Thinking of documents as electronic, there are features like HTML.

HTML is simply character strings (or alternatively a DOM node tree), what has this got to do with an IDE?

IDE's offer various techniques for debugging. The current computer languages that I know define ways to insert debug code and comment it out or insert it using macros that can be disabled. In a printed document this is distracting clutter.

I haven't seen printed source code for 20 years. And if the debug code still needed to be there, what is the point in having a hard copy without it?

In an electronic document, we can imagine the document having various versions and having one version that makes debug code invisible.

Different versions; how would you keep them consistent? It would make more sense to flag the debug code in some way and allow the IDE to hide it if requested. This could easily be impemented currently (e.g. with a JavaDoc style flag) - but I don't know of any IDE that does this, probably because this is not something programmers want (generally debug code should be deleted once the program works, debug code is not a alternative to regression testing).

In C, there is the distinction between "#include < name.h>" versus "#include "name.h"".

But they look for files in different places - and they are defined the way they are precisly to AVOID filesystem issues (e.g. Windows %PATH% and posix PATH).

I'd prefer to have all the filesystem issues handled in some systematic way

Then you would be tying your language to a particular filesystem. In practice all portable languages have a library abstracting the runtime filesystem, and this is nothing to do with the IDE.

- perhaps a computer language needs a sub-language just to handle file system issues. We could even have two different languages for handling computations that employ the same sub-language for handling file system issues.

One way to look at the situation is this: A language must be designed so it can be implemented by current technology to do certain computations. One step in this implementation is compiling or interpreting the program. Hence file systems (or more abstractly, information retrieval systems) must be navigated. If there is a utility in abstracting the notion of computations then there should be a utility in having a language that abstracts the notion of information retrieval.

I don't understand what you mean: can you provide a concrete example of a language that does not abstract the notion of information retrieval?

 

[Stephen Tashi]

I don't understand what you mean: can you provide a concrete example of a language that does not abstract the notion of information retrieval?

I know of no current computer language that abstracts the notion of information retrieval in a systematic fashion. Languages have ad hoc aspects that affect information retrieval, such as the class naming convention in Java.

The basic aspects of information retrieval (for the purposes of compiling or interpreting) are:

1. Within the data for computer code, what are the identifiers that label the information to be retrieved? (e.g. What is the identifier for a function used in this document, whose code is not part of this document?)

2. What are the identifiers for the places where the data for the code is stored? (e.g. What is the name of the file that stores function whose identifier is "int f234( int k)" ?)

Of course, it's convenient if the name of the file that stores in information for "int f234(int k)" is simply "f234" or "intf234" and the naming of public classes in Java is an example of an attempt to enforce a relation between aspects 1. and 2.

One might take the attitude that only aspect 1. should be treated in the definition of a computer language. From this point of view, computer code should not contain statements that deal with the file names for places where code is stored.

A contrasting view is that a computer language should associate each object in the language with an abstract file identifier and that particular implementations (compilers, linkers) would be configured to map the abstract file identifiers to particular files.

Current computer languages treat aspect 1. in a reasonably systematic manner. The way they handle aspect 2. is not systematic.

 

[pbuk]

I know of no current computer language that abstracts the notion of information retrieval in a systematic fashion. Languages have ad hoc aspects that affect information retrieval, such as the class naming convention in Java.

The basic aspects of information retrieval (for the purposes of compiling or interpreting) are:

1. Within the data for computer code, what are the identifiers that label the information to be retrieved? (e.g. What is the identifier for a function used in this document, whose code is not part of this document?)

I don't understand what "information retrieval (for the purposes of compiling or interpreting)" or "the data for computer code" are - are you simply talking about source code?

2. What are the identifiers for the places where the data for the code is stored? (e.g. What is the name of the file that stores function whose identifier is "int f234( int k)" ?)
...
Current computer languages treat aspect 1. in a reasonably systematic manner. The way they handle aspect 2. is not systematic.

But these things are entirely implementation dependent: in the GNU C++ compiler on Linux the source code for cin is containted somewhere like /usr/include/stdio.h which is compiled into the executable whereas in Microsoft Visual C++ the object code for cin is implemented in the DLL (dynamic link library) C:\Windows\System32\vcruntime140.dll which is linked in at runtime.

So the definition of include in C++ IS systematic, it is the implementation that is different. Other languages are similar - Python's and Java's import, Node JS's and Ruby's require, even PHP's include, they are all filesystem independent.