[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? [Peter Newman] See below. And Yes you will be able to download the code that creates 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. [aricb] I'm fairly certain I understand your proposal, and I think your ideas that are interesting. But I personally don't see a need for UPL; I disagree what I understand are the motivations for UPL, and I also think that the proposal as it now stands doesn't adequately address your concerns with the current state of Tcl/Tk. I'm hoping you'll explain in more detail what you feel are the shortcomings of Tcl/Tk and how UPL fixes them. The size of the core has less relevance than the size of the language as a whole, don't you think? Somewhere, somehow, you've got to implement a useful language, whether in one big piece or several little ones. The "monolithic" model has some distinct advantages over the "many small pieces" model. Code fragments that are applicable to multiple parts of the core need only be present once in the monolith. For example, several core commands internally use hash tables. With a monolithic core, you need only code up one hash table framework and all commands that need it have access to it. Under your proposal, either you have to provide a separate hash table framework as part of each "command module" that uses one, or you have to make each relevant module depend on a separate hash table module. If you go with the first plan, your code mushrooms and becomes highly redundant. If you go with the second plan, your code not only retains the interdependencies you were concerned about, but makes matters worse by requiring one more module for everybody to deal with. I understand that you want to be able to cobble together your own custom language for each program you write. That sounds painful to me, but to each his own. But somewhere, either on your computer or on the end user's computer or both, is going to be not just the language you've put together, but all the commands of all the languages in UPL. Otherwise, how can you write or run a UPL program? And that truckload of code, whether it's in the core or elsewhere, is going to be huge. But even if you figure out some way so that the only code that has to be on anybody's computer is the code that provides whatever language you put together, if that language is going to allow the programmer to do something useful, at best it is going to approach the size of the Tcl/Tk core, and I suspect it is going to be much bigger. So my understanding is that the UPL core is going to be small, the UPL library is going to be gargantuan, and any given practical command set built with UPL (prerequisite for any useful program written in UPL) is going to range from Tcl/Tk-size to very much bigger. And to write a UPL program, in addition to the time you spend writing the program, you're going to have to invest the time to piece together a working language, as opposed to sitting down and writing a Tcl/Tk program, assured that the entire pre-packaged, fully functional core is at your disposal. As I see it, UPL is less efficient in terms of time and space. How is this better than what we have now? I don't mean to be rude or to belittle the considerable time and effort you've put into this. But I can't "buy" UPL until I understand what's wrong with Tcl/Tk and how UPL fixes it (without introducing so many more problems that I'm forced to stay with the lesser of two evils :). [DKF]: The other problem with doing lots of DLLs is that it becomes quite a bit slower to start the system up (where that counts as the point when, say, you get the splash screen up or start accepting network connections if you're a server app.) [Peter Newman] 13 January 2005: Thanks [aricb]. I've obviously got a lot more explaining to do. But it's going to take some time (as in weeks/months). I've only got limited time; so must chip away at it slowly. ---- [Category Discussion]