Version 15 of UPL: No Core - No Core Team

Updated 2005-01-11 21:43:46

Peter Newman 8 January 2005 ------------------ Unified Programming Language

Cores IMHO, are the root of all evil (in programming languages). So UPL doesn't have one.


LV Define what you mean by core. I know some people use the term to be the code that is compiled together to create a language. Are you saying that one won't be able to download code that compiles to create UPL?


Instead, every data type and command/function is a stand-alone, script level programmer selectable entity.

In other words, every programmer can create their own personal programming language - by selecting the data types and commands/functions they want.

These are selected by editing UPL: The Bootstrap File.


DKF: You have to have some core because that core is responsible for the bootstrap process.


Peter Newman Yeah you're right. Also I suppose the API between different components can be be considered part of the core too. But note that NO scripting language data types or functions/commands are part of the core. That's the important thing.


aricb Peter, this idea that "the core is the root of all evil" seems to be one of your main motivations for proposing UPL. But I have yet to see a convincing argument for this position. The two complaints I seem to remember hearing from you are: the core is too big, and the core is too complex because different parts of the core are too interdependent. I suppose these are matters of taste, but I don't see how the current proposal for UPL resolves either of these concerns. Okay, UPL has a minimal core, but somewhere in there is code to implement every programming language known to mankind. These pieces may or may not be interdependent, but on one or the other level there is going to be a lot of redundancy, which implies complexity of a different kind and a size a few orders of magnitude greater than the Tcl core will ever reach. Even if all I want out of UPL is Tcl, I can't imagine that the end result (UPL minimal core + TCL module + whatever else it takes to make it run) will be smaller than today's Tcl.

Maybe this is an unfair assessment of your position on the core and/or I'm missing something key about UPL. If so, can you explain why the core is the root of all evil and how UPL fixes it?

DKF: It just occurred to me that we've already got the kind of core Peter's after.

It just happens to be machine-readable instead of human-readable. It's usually called something like crt0.o...

WHD: I might add that the different parts of the core are interdependent for a reason. Consider the regular expression module, which is used all over the core by lots of different commands. With the proposed UPL architecture, you'd have to choose one of these possibilities to get the same functionality:

  • Put the regular expression code in the core, but not the "regexp" and "regsub" commands. Any command can use the regular expression facility. Only now the core is more than a bootloader.
  • Each command that needs regular expressions provides its own regular expression code. Please, let's not even go there.
  • Commands are written so that if a regular expression module is available they use it, and if not not. This is certainly doable, but I suggest that it's a maintenance nightmare.

PWQ 12 Jan 05, while I don't want to answer for Peter, It would be both facile and trivial to engineer a system that allowed regexp to be a module that is included or not but at the same time be shared by those commands (ie lsearch string glob) that can use it (if present).


Peter Newman 12 January 2005: I've got a feeling that there might be a little bit of confusion as to what is meant by the term core.

To me, the core is the script level Tcl commands (set, expr, string, file, etc, etc); data types (scalar (variables with a single value), list, array, dict, etc), and; variable scopes (local and global); etc - that the script level programmer sees.

But it doesn't include what - from now on I'll refer to as the kernel - which in Tcl/Tk comprises:-

  • The Tcl C API
  • The Tk C API
  • Any third party libraries used by the above - such as Henry Spencer's Regular Expressions Library, or the PNG Library, etc.

So in UPL Tcl/Tk there will still be a kernel - which the core script-level commands will no doubt make use of to do their magic.

The difference is simply that, instead of compiling all the core commands into a single monolithic executable (with supporting DLL/so's), each core command or data type will be a completely independent stand-alone module (in dll/so format,) which the script-level programmer can include or exclude from their own personal version of the language as they see fit.

I've got the feeling that some people thought I was suggesting we throw away the Tcl and Tk C API's - which isn't the case.


Category Discussion