Second Edition Proposal

[arielf212]

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:

1. It's really hard to differentiate between variable and procedure names (aka identifiers) and sentence words. Look at the following example:

DATA:
two is number
....
PROCEDURE:
CREATE STATEMENT "Multiply $ by $" exectuing Multiply
CREATE STATEMENT "Multiply $ by two" exectuing MultiplyByTwo
....
Multiply 4 by two

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:

DATA:
two is number
....
PROCEDURE:
CREATE STATEMENT "Multiply $ by $" exectuing Multiply
CREATE STATEMENT "Multiply $ by two" exectuing MultiplyByTwo
....
Multiply 4 by two
# or alternatively:
Multiple 4 by $two 

2. most of the "built-in" statements should be either removed or moved to the standard library. 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.

[xvxx]

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.

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 import X and the tools will be already available to you:

The Python source distribution has long maintained the philosophy of "batteries included" -- having a rich and versatile standard library which is immediately available, without making the user download separate packages. This gives the Python language a head start in many projects. — https://www.python.org/dev/peps/pep-0206/

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.

[arielf212]

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:

most of the "built-in" statements should be either removed or moved to the standard library.

[xvxx]

@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 :+1: on including the standard library with LDPL when you install it.

[arielf212]

ah, I didn't realize that ^^'. I just assumed it was included because of the name. Thank you for correcting me!

[Lartu]

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.

[Lartu]

@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!

[arielf212]

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. IMO, the less compiler magic exists in a language, the better (since you can lookup how a procedure works just by looking at an ldpl file, instead of reading the compiler code).

EDIT: also, I just subbed to the mailing list.

[Lartu]

@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.

[arielf212]

Actually, there is probably no overhead to calling such a function since any decent compiler worth it's salt will inline its body.