Which way the language prefers to be encoded？

[hnlcf]

When we face a new language, we mainly consider the following three aspects (from SICP lecture-1a).

1. What are the basic elements (primitives)?
2. Ways to combine these primitives
3. Methods for abstraction

The documentation described hopefully incorporates the strengths of several modern languages, but nothing is ever perfect.

We need to define a major direction for the language from the beginning and highlight it (Seems more functional?), as for other paradigms can be left as an additional choice for developers, otherwise it will just create another C++ (I believe you definitely don't want to do this).

As for some language specific things, it is more of a tactical choice than a strategy.

By the way, isn't the keyword omitted too much?

[starr-evan]

Sorry my English is not very good, here is my reply：
Silk is currently in the early draft stage and hasn't been developed in a specific direction yet. Therefore, establishing a major direction is the primary task. I hope that Silk has many features of modern languages (generics, type inference, closures, modularity, etc.) and also has its own characteristics - providing more flexibility and conciseness without losing type specifications. However, I am not completely satisfied with my established direction. On the one hand, I want Silk's syntax to be very concise (no need for variable declarations with "let",types like "chr", "str", "flt", "int" ), but on the other hand, I find it hard to give up using symbols that are initially difficult to understand in Silk. Therefore, there is a contradiction between the two. (The use of symbols looks concise, but it's hard to understand). Anyway, this is a specific direction currently and I will make a decision later.
I have only slightly completed the lexical analysis so far, which is still very imperfect. The reason why I did not continue to complete it, because now the starting point should be this language level of conceptual design, writing Silk design concept and outline, this is the most need to implement.

1. What basic elements does Silk consist of?

The basic elements use only 'int' (integer), 'flt' (floating point), 'chr' (character), 'str' (string), 'bol' (boolean), which are indivisible. The rest of the types are all 'Box' types.

2. How to combine these basic elements?

I plan to use 'Box' to combine these types. The internal implementation of 'Box' has not yet been considered, but it can't escape the fact that it's a 'struct' or 'class' in everyone's eyes. The function type should also be a 'Box', the function type constructed by 'Box' is 'F'. arr1 = [1,2,3,5,8]"Person = * { name:" Xiaoming", age: 24} , tuple = | "OK", 200 | ...these are just syntax sugar, themselves are Array, Table and tuple, Eventually are Box.

Here's how the Box type is built:

box Bird {
	name = "Polly"
	animal_type = "parrot"
	eat = -> "Polly is eating."
  cry = -> "Polly is making a sound."
	fly = -> "Polly is flying."
}

Building a Box should be flexible, and it can also use literal quantities:

bird2 :Bird = box {
name = "Polly"
animal_type = "parrot"
eat = -> "Polly is eating."
cry = -> "Polly is making a sound."
fly = -> "Polly is flying."
}

You can also build like this

bird:Bird = {
    name = "Polly"
    animal_type = "parrot"
    eat = -> "Polly is eating."
    cry = -> "Polly is making a sound."
    fly = -> "Polly is flying."
    -> @ //return the code block itself. @ represents "self"
}

Box can complete the combination of types in Silk.

3. how to achieve abstraction?

My current idea is to use an interface-like field, "Ability," to build an abstract description of a Box.

ability CanSolveArea {
    position: | int, int | //2 tuple represents a coordinate
    f area():int
}

In fact, I think ability should have a more powerful function than interfaces in other languages, allowing Silk's"Engineering" and"Abstracting" flexibility, this is the point that needs to be addressed now with imagination as well as with reality.
In addition, bond can reflect the flexibility of Silk: bond can be one or more types of collection. A variable doesn't correspond to a type, it corresponds to a bond ('a_1: int = 1' is actually a bond of type a_1, which is a collection of type int only) . The developer doesn't have to worry about which specific type the variable is currently in, as long as the variables are the same bond, they can be converted and interacted with each other (which I think gives the Silk language a lot of flexibility)

bond num = int | flt
a:num = 1
b:num = 2.0
log(a+b) // 3
...

Developers can define their own bond, and use ability to program their bond to deal with different situations programmatically. For example, developers can use bond and ability to make code like this work: 'false + 1 == true' .
So the task now is:

1. Supplement for ability
2. The possibility of Bond realization, the evaluation of the advantages and disadvantages of bond.
   Thanks again for your answers, your questions and suggestions are a great contribution to Silk before it hatches.