search

basilTeam / basil

Fast and flexible language exploring partial evaluation, context-sensitive parsing, and metaprogramming. Compiles JIT or AOT to native code.
BSD 3-Clause "New" or "Revised" License
123 stars 11 forks source link

Create standard library #9

Open minchingtonak opened 3 years ago

minchingtonak commented 3 years ago

One of the most important elements of making Basil more accessible to new users is providing those users with access to useful library functions. In its first form, this will look like:

Each separate category of operation will be defined in it's own file, allowing users to import library functions as they're needed.

The overall goal for the Basil standard library is to be easy to use and to have enough breadth that it covers the majority of programmers' average use cases.

elucent commented 2 years ago

This deserves deeper discussion and evaluation - how much of a stdlib do we consider necessary for 1.0? Adding this to the 1.0 release column, but it might be reasonable to split this up.

dumblob commented 2 years ago

I think that the stdlib which will be forever shipped (and forever maintained) with Basil shall be really minimal (let's call it a tier 1 stdlib) and have strong focus on "meta" things.

What I mean by "meta" is to meticulously define and technically enforce "namespace" division and related release & distributed (among different groups with different goals - e.g. commercial sector vs academia vs consumers etc.) management.

This is to avoid the disaster which happened to the Tcl ecosystem. I.e. people wanted to write lots of Tcl extensions and modules but because of missing coherent structure how such separately (totally in isolation) developed code should mix with other such code, Tcl struggled for about 20 years to slowly and very painfully reintegrate a (rather small) subset of the extensions & modules into the official distribution.

  1. The concept of from future import X, Y, Z or alike is inevitable and has to be strictly enforced by technical means. It seems to be so far the best solution to the problem of getting a new behavior of the lang only in strictly delimited parts of the program.
  2. There has to be a solution to allow development of several (many) "different stdlibs" designated as "tier 2 stdllibs" and to allow mixing them safely (including mixing two versions of the same tier 2 stdlib project).
  3. The minimal standard library (tier 1) should thus comprise of macros which meet a certain level of quality (e.g. support many different platforms, guarantee compile time error if the Basil version they're being tried to run on is incompatible, have tests, etc.). Over time this'll accumulate a small amount of carefully chosen stuff from tier 2 stdlibs, but hopefully not much. The point is to always have a way to say suddenly STOP and simply switch to an alternative tier 2 stdlib as the new default.
  4. There shall be one chosen tier 2 stdlib to be distributed with Basill by default but it should be made explicit that it's a "flavored Basil" and that this "flavor" can change any time (among major versions of course; not in minor nor bugfix releases).
  5. Maybe use SemVer?

Thoughts?

Imagine I would want to create a tier 2 stdlib which would transform Basil into a fully dataflow language (e.g. a shell-like language with pipes everywhere and no traditional sequential code). So in other words, nothing in tier 1 must prevent me from doing this without having to fight some weird tier 1 (anti)features.