New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Second Edition Proposal #189
Comments
That’s not what “batteries-included” means, though. It means that once you install Python, you don’t need to install more packages to get work done. You can just
All of Python’s standard library, which is installed alongside Python, is what the “batteries-included” philosophy is about. The “time” module is part of that. If you go here, you can see that Python’s standard library has more modules than LDPL has functions: https://docs.python.org/3/library/ I would be happy to see LDPL’s functionality more organized, but not if it means having to install more packages over the internet after you’ve already installed LDPL. There’s just not point in forcing someone to download a “time” module after they’ve installed LDPL when only one “time” module exists. If there were multiple and they had to pick one, sure, but all we’re doing is adding friction. And making it more difficult to get started than with, say, Python. |
I think you misunderstood what I meant. I know exactly what "batteries-included" means. What I am for is moving all of the really specific "built in" sentences into stdlib modules that come installed with the language and one can freely load when he needs them, just as I highlighted here:
|
@fireofgods LDPL's standard library doesn't come with LDPL, you have to install it separately: https://github.com/lartu/ldpl-std So I think we agree, I am 👍 on including the standard library with LDPL when you install it. |
ah, I didn't realize that ^^'. I just assumed it was included because of the name. Thank you for correcting me! |
That's actually a great idea @xvxx (i'm back!), I will be working on that. The standard library and a number of other useful libraries (sockets, for example) should be included with the language and installed alongside it. |
@FireofGods, regarding breaking changes, I wouldn't mind jumping to some LDPL 5 with a breaking API and I wouldn't mind forcing the users to preppend $ to the variable names (in fact, in a pre-release version of LDPL (called COBOLARTU), that was how variables where written). If we did this, I'd propose we also move into some compiler-compiler technology, like Antlr (that I used for LAPL) to make the codebase cleaner. In any case it will be a ton of work though. If you want to, you could sign up to the LDPL mailing list and we can plan on how to tackle the task there. It would be a fun endeavour! |
Actually, the reason I suggested the $var thing is because it will explicitly make writing a handmade parser a bit easier. Also, I still haven't heard your stance about putting most of the builtin sentences into the standard library. EDIT: also, I just subbed to the mailing list. |
@FireofGods if we were to use something like Antlr, there would be no need for $. I do like the $var syntax though, it's visually appealing. Regarding the standard library, I'm not against that for some statements. ADD $ AND $ IN $ could obviously be moved to the standard library, but it just adds a lot of overhead and function calling to a simple addition opperation, so I wouldn't move it. Maybe the time statements could be moved without so much overhead. That should be evaluated for each statement individually. I don't really mind a giant language with lots of built in statements; this is COBOL with a dinosaur after all, minimalism is way out of the picture haha. |
Actually, there is probably no overhead to calling such a function since any decent compiler worth it's salt will inline its body. |
In my opinion, ldpl has a few problems which are integral to the language and thus can only be fixed as a breaking change. In order to minimize the amount of breakage that might happen, I propose releasing an update to ldpl which is similar in nature to python's 3.0 update.
The two major problems this language suffers from are:
Look at the following example:
Which of the two statements gets executed? While there is probably an answer to this, It's not immediately obvious.
What I propose is to force the use of the dollar sign ($) before use of variable names, which would solve the problem of ambiguity. with this fix, the example will look like this:
Even python, a language known for its "batteries-included" approach, doesn't have as many built-in functions as ldpl. For example all of the time statements need to be moved to a time module.
The text was updated successfully, but these errors were encountered: