A New Ada-derived Language

General
1

Here it is : Re: Ichbiah 2022 compiler mode - Randy Brukardt

(if we start discussing this other path, it would be preferable to create another discussion so that this one stays focussed on Ada 83)

2 Likes
2

I’m happy for it to be broken off into another thread.

1 Like
3

What is ODT in that context??

4

I thought it was a typo and meant Abstract Data Type.

1 Like
5

But he uses it more than once.

1 Like
6

Object Data Type, I guess.

1 Like
7

Yeah, that was my conclusion too.

8

Titania wouldn’t be a subset, but a new language and that is what we are talking about here, a new language.

9

Right, sorry. Changed the topic to reflect that.

1 Like
10

Yeah, I changed it at the same time, yours overrode mine.

After talking to @OneWingedShark about his ideas for an Ada compiler, and that I said that Titania should have traits, I think it needs to go deeper than that.

I also noted it should be parallel from the outset, there’s no reason why something like tasks could not be built on top.

I’ll be looking into this project more next year.

11

Would that discount a light runtime capability?

12

I don’t know, lighter, possibly, that is dependent on what is provided in the runtime library. But again, that is dependent on what I end up with as the base language and what is required for a decent runtime on various platforms.

But given I would probably want to write an OS with it, the ability to strip it back makes sense.

On reading that thread on nntp, the idea of having a fairly liberal parallel syntax which can be restricted if required seems to be the best option.

13

Have you folks looked at Austral? Seems like an interesting little language with Ada/Wirth-style syntax, but with linear types for memory safety: https://austral-lang.org/

Perhaps interesting to take a look at.

1 Like
14

I’m in line with some of J. Ichbiah point.
Obviously, It’s always more easy when you don’t have the other side arguments.
But he had strong arguments.

And I’m very sensitive to the aesthetic aspect of the language, even if one could consider it totally subjective.

One of the point is the hardware evolution. I remember (first job) working on a huge project on VMS. All subsystems where dependent on one big package with types exchanged between those subsystems.
This package was only compiled during the week-end, to avoid paralyzing the team and the servers during 5 or 6 hours. And on Monday morning, it was the big question, does all compile fine, or should we wait more? :slight_smile:

Today, the whole project would probably compile in less than ten minutes on my mini computer.

This lead to discussing the necessity of child packages, as done by J. Ichbiah, but also questioning the relation between the language and it’s compiled or interpreted nature. I dream to be able to use the same language from a 5 lines interpreted script to a 100k lines industrial compiled and formally proved software.
I dream of a Freecad with an OCCT in Ada (the new one) instead of C++, and Ada as extension language instead of Python. Or a Neovim in Ada / Ada instead of C / Lua.

Those constraints are tremendously antagonists.
But I would be curious to see where we can go with this heretic specification, starting with the simplest language, and adding useful trait progressively.

Some have already made scripting language on an Ada basis, could be worth considering Ken O. Burtch https://sparforte.com/ for example.

15

Did not remember that, but it seems I’m not the first dreamer!

When I began SparForte more than 20 years ago, I was concerned about scalability from the shell prompt up to large applications. I wanted to design a scripting language that balanced the needs of both low and high, as programs changed over time

16

More in the spirit of a future language, Jeff Carter’King :

For an idea of what I think a language should have, you can look at my informal description of King
(GitHub - jrcarter/King: An informal decsription of the King software-engineering language).

17

Interesting (even if Iack Haskell culture).

As always, the list of what is banned is as interesting as the list of what is wanted.
(Features)

This one will be discussed here for sure :slight_smile:

  • No exceptions (and no surprise control flow).
18

I think this is the wrong-way-around.
Instead of trying for “simple, then we add on” we should have the complex constructs already modeled. — To illustrate: if the trait-system is enough to define the “shape” of types, to use the type-system to define the type-system, you can then use that mechanism to define the Standard types. — By doing this you get a more uniform language, with fewer surprises and use the language to help guide both implementors and new-users.

I would actually recommend dividing the trait-system into two parts:

  1. The “language-usage” part, meaning how the item “fits” in the language, the “abstract interface”, if you will.
  2. The properties that the implementing-type must provide, where you can “hang proofs on”, what is termed an ADT in CS.
  3. (optional) A construct for applying these together, on the abstract level: so that you can represent parameters
    1. on the concrete level (e.g. Function K( X : in Object ) return Thing;)
    2. on the abstract level (e.g. Generic X : in out Integer; Procedure K is…)
    3. on the structural level (e.g. For P in parameter loop, or something that would be retrieved with SELECT * FROM Procedures WHERE parameters = (Integer, float, float))

Being case-sensitive was an instant deal-breaker for me.

19

Don’t need to dream, you already have it with “Full Ada” / HAC :slight_smile: .

2 Likes
20

Same reaction from my side, but don’t throw the baby out with the bathwater, SparForte may be a source of inspiration for something else. :slight_smile: