Add specification
This commit is contained in:
chakr
parent
e126444105
commit
ce64bd92cd
61
README.md
61
README.md
|
|
@ -1,3 +1,60 @@
|
||||||
# project-iglishmek
|
# *Iglishmêk* Programming Language
|
||||||
|
|
||||||
Home of the "Project Iglishmek" Programming Language
|
## What is *Iglishmêk*?
|
||||||
|
|
||||||
|
*Iglishmêk* is the hand gesture language used by the dwarves in Tolkien's Legendarium
|
||||||
|
|
||||||
|
## Ok sure, but what is the *Iglishmêk* programming language?
|
||||||
|
|
||||||
|
*Iglishmêk* is an esoteric programming language that is trying really hard to be a serious programming language.
|
||||||
|
|
||||||
|
It is inspired by both serious programming languages like C, C#, Lisp, Lua, Rust, Go, Odin, Zig, Elixir, and Haskell; but also [esoteric programming languages](https://esolangs.org/wiki/Esoteric_programming_language), like [var'aq](https://web.archive.org/web/20091026213516/http://geocities.com/connorbd/varaq/) and [ZOMBIE](https://web.archive.org/web/20201125123312/https://www.dangermouse.net/esoteric/zombie.html).
|
||||||
|
|
||||||
|
## What are the features in *Iglishmêk*?
|
||||||
|
|
||||||
|
In general the paradigms are designed to be: Esoteric, C-like, Functional, Distributed, Concurrent, JIT
|
||||||
|
|
||||||
|
Most especially I wanted it to be written in C which is the lingua universalis of most hardware, architectures, operating systems, and so on. So that if anyone for any reason, even if it is for a joke, port Iglishmêk to any known system that has a C compiler for it without *too* much trouble.
|
||||||
|
|
||||||
|
See the [SPECIFICATION](./SPECIFICATION.MD) document for more info.
|
||||||
|
|
||||||
|
## What is the purpose of this language?
|
||||||
|
|
||||||
|
Its a pretty common question for people in computer science and programming related fields "what is your favorite programming language", and for me it has changed a lot over the years. I got to the point where I would say I don't really have one. I like elements of a lot of languages and don't like other elements from those same languages.
|
||||||
|
|
||||||
|
There are a lot of languages that have good functionality and implement good ideas, but also many bad things that creep in during the process of development.
|
||||||
|
Examples of this could be through lack of resources, backwards compatibility, trading off one feature for another, and many others.
|
||||||
|
|
||||||
|
For the most part though, most modern languages are pretty much the same syntactically, they just differ for their paradigms and use case. This makes them a super dry and not very fun to program in.
|
||||||
|
|
||||||
|
Conversely we have esolangs which are fun, but usually useless (e.g. turing tarpits) or not implemented in a way that you are able to seriously program projects in it.
|
||||||
|
|
||||||
|
Most serious languages do not take the time to think outside the box, or add elements to make the language look good or be fun to program in.
|
||||||
|
|
||||||
|
There are of course some exceptions to this. Python has dynamic whitespace, which although I dislike personally, has a great esthetic and makes the code look cleaner. Or like in Odin you can use emoji as variables.
|
||||||
|
|
||||||
|
All of the others were esoteric languages or languages designed to be used for games (e.g. golfing languages, video game specific languages such as TIS100, and the like).
|
||||||
|
|
||||||
|
Lets get back on track though as to why *this* language.
|
||||||
|
|
||||||
|
As far as my personal goals go they are:
|
||||||
|
1. I wanted to learn about compiler design and create one
|
||||||
|
2. Mess around with some old, obscure, or just plain weird language design ideas
|
||||||
|
3. Combine these ideas into a language that would be both fun and able to be used for real projects; probably more along the lines of scripting, or small scale programs, but real projects nonetheless
|
||||||
|
4. Take all the things I liked from some languages and throw them together to see what happens
|
||||||
|
|
||||||
|
|
||||||
|
The language goals are:
|
||||||
|
1. maximize code logic density, i.e. a small amount of code should represent a complex amount of logic
|
||||||
|
2. portability/embedability, i.e. should be easy to port/embed into new hardware and implement with software
|
||||||
|
3.
|
||||||
|
|
||||||
|
The idea is using an iterative process, that being as I find new programming projects to do; the language will inevitably fail to be able to handle that project and so I will have to add new functionality to *Iglishmêk* to handle it.
|
||||||
|
|
||||||
|
I should say that I would not expect *Iglishmêk* to do much, but it will do something
|
||||||
|
|
||||||
|
## Thanks
|
||||||
|
|
||||||
|
[Crafting Interpreters](http://www.craftinginterpreters.com/) Inspiration for
|
||||||
|
|
||||||
|
Compilers Principles, Techniques, & Tools (The Dragon Book)
|
||||||
|
|
|
||||||
|
|
@ -0,0 +1,680 @@
|
||||||
|
# *Iglishmêk* Design parameters
|
||||||
|
|
||||||
|
## Modern programming languages in the 21st century usually have need for the following requirements
|
||||||
|
|
||||||
|
### Data
|
||||||
|
|
||||||
|
- describing data
|
||||||
|
- numeric
|
||||||
|
- string
|
||||||
|
- logical
|
||||||
|
- complex
|
||||||
|
- point
|
||||||
|
- edge
|
||||||
|
- color
|
||||||
|
- many more
|
||||||
|
- qualitative
|
||||||
|
- sentiment analysis
|
||||||
|
- more...
|
||||||
|
- measurements
|
||||||
|
- tons of these...
|
||||||
|
|
||||||
|
### Inputing data
|
||||||
|
|
||||||
|
- stdio
|
||||||
|
- program args
|
||||||
|
- command line
|
||||||
|
- reading from other source
|
||||||
|
- gui
|
||||||
|
- input boxes
|
||||||
|
- forms
|
||||||
|
- many others
|
||||||
|
|
||||||
|
### Storing descriptions of data
|
||||||
|
|
||||||
|
- internal
|
||||||
|
- graph
|
||||||
|
- array
|
||||||
|
- list
|
||||||
|
- set
|
||||||
|
- map
|
||||||
|
- external
|
||||||
|
- database
|
||||||
|
- local
|
||||||
|
- cloud
|
||||||
|
- writing data
|
||||||
|
- stdout
|
||||||
|
- stderr
|
||||||
|
- writing to other source
|
||||||
|
- file
|
||||||
|
- tape
|
||||||
|
- socket
|
||||||
|
|
||||||
|
### Manipulating data
|
||||||
|
|
||||||
|
- algorithms
|
||||||
|
- sort
|
||||||
|
- filter
|
||||||
|
- math functions
|
||||||
|
- trigonometric
|
||||||
|
- statistics
|
||||||
|
- calculus
|
||||||
|
- many more
|
||||||
|
- Validating data
|
||||||
|
- business rules
|
||||||
|
- constraints
|
||||||
|
- formulas
|
||||||
|
|
||||||
|
### Displaying data
|
||||||
|
|
||||||
|
- objects
|
||||||
|
- 3d models
|
||||||
|
- 2d models
|
||||||
|
- graphs
|
||||||
|
- tables
|
||||||
|
- infographics
|
||||||
|
- written output
|
||||||
|
- ai generated text
|
||||||
|
|
||||||
|
### System/World Objects
|
||||||
|
|
||||||
|
- Viewing objects in nth dimensional space
|
||||||
|
- Animations
|
||||||
|
- moving the objects in space
|
||||||
|
- manipulating objects
|
||||||
|
- Interaction from user input on objects in space
|
||||||
|
- Creating
|
||||||
|
|
||||||
|
### Communication
|
||||||
|
|
||||||
|
- Sending and receiving data
|
||||||
|
- protocols
|
||||||
|
- Controlling real world objects
|
||||||
|
- embedded programs
|
||||||
|
- web programs
|
||||||
|
- mobile
|
||||||
|
- desktop
|
||||||
|
- smart devices (IOT)
|
||||||
|
- Encryption
|
||||||
|
- hashing
|
||||||
|
- keys
|
||||||
|
- more ...
|
||||||
|
|
||||||
|
### Meta
|
||||||
|
|
||||||
|
- documentation
|
||||||
|
- tutorials
|
||||||
|
- generating objects automatically like
|
||||||
|
|
||||||
|
### Data Description
|
||||||
|
|
||||||
|
- windowing system
|
||||||
|
- window
|
||||||
|
- terminal
|
||||||
|
- web browser
|
||||||
|
- form of the object (description)
|
||||||
|
- version number
|
||||||
|
- fields
|
||||||
|
- forms
|
||||||
|
- what dimensional object
|
||||||
|
- unit form / measurements
|
||||||
|
- display
|
||||||
|
- What the UI default should be
|
||||||
|
- type of display
|
||||||
|
- position in space
|
||||||
|
- user controls
|
||||||
|
- validations
|
||||||
|
- communications
|
||||||
|
- CRUD
|
||||||
|
- create
|
||||||
|
- read
|
||||||
|
- update
|
||||||
|
- delete
|
||||||
|
|
||||||
|
# *Iglishmêk* Grammar and Specification
|
||||||
|
|
||||||
|
## Form
|
||||||
|
|
||||||
|
- describe storage objects "the ideal state of the object"
|
||||||
|
- atoms (invoked forms) are stored in the internal database which is why they need version numbers
|
||||||
|
- Forms can be inherited, multiple inheritance is taken from left to right overriding collisions.
|
||||||
|
- there are also a list of "substantial forms" which come with the language which are the building blocks for more complex forms. If you are coming from object oriented languages you can think of this as "primitive types"
|
||||||
|
- all forms derive from the root form or the "parent of all forms"
|
||||||
|
|
||||||
|
```
|
||||||
|
frm «form_token» impls «this_form», «that_form» {
|
||||||
|
version : [0, 0, 1] ! version number for auto saving to a database or whatnot
|
||||||
|
migrate : <> ! this is to migrate from the previous version to new, in case of interface changes, or None
|
||||||
|
dimensions : 0 ! this returns how many dimensions it can exist in, 0th means non drawable, 2 means 2D GUI usually, 3 means 3D object, and >3 is somthing you will have to implement yourself, e.g. miegakure
|
||||||
|
unit : <> ! this is for the unit/measures system
|
||||||
|
display : <> ! some kind of UI form or None
|
||||||
|
position : <> ! a position in space or None
|
||||||
|
! form definitions here
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
# Substantial Forms
|
||||||
|
|
||||||
|
## numeric
|
||||||
|
|
||||||
|
### bit (or unsigned units)
|
||||||
|
|
||||||
|
`u8, u16, u32, u64`
|
||||||
|
|
||||||
|
### integer (signed)
|
||||||
|
|
||||||
|
`i8, i16, i32, i64`
|
||||||
|
|
||||||
|
### real
|
||||||
|
|
||||||
|
`f32, f64`
|
||||||
|
|
||||||
|
## string
|
||||||
|
|
||||||
|
`str`
|
||||||
|
|
||||||
|
matching `''` for char
|
||||||
|
|
||||||
|
matching `""` for string
|
||||||
|
|
||||||
|
strings are always utf8, other formats will need to be done manually
|
||||||
|
|
||||||
|
## measurement
|
||||||
|
|
||||||
|
- forms
|
||||||
|
- time
|
||||||
|
- unit
|
||||||
|
- seconds (s)
|
||||||
|
- subforms
|
||||||
|
- date
|
||||||
|
- Default is ISO 8601
|
||||||
|
- length
|
||||||
|
- unit
|
||||||
|
- metre (m)
|
||||||
|
- subforms
|
||||||
|
- angle
|
||||||
|
- radian (rad)
|
||||||
|
- mass
|
||||||
|
- unit
|
||||||
|
- kilogram (kg)
|
||||||
|
- electric current
|
||||||
|
- unit
|
||||||
|
- ampere (a)
|
||||||
|
- temperature
|
||||||
|
- unit
|
||||||
|
- kelvin (K)
|
||||||
|
- amount of substance
|
||||||
|
- unit
|
||||||
|
- mol (mol)
|
||||||
|
- luminous intensity
|
||||||
|
- unit
|
||||||
|
- candela (candela)
|
||||||
|
|
||||||
|
## logical
|
||||||
|
|
||||||
|
`bool`
|
||||||
|
|
||||||
|
`true` / `false`
|
||||||
|
|
||||||
|
Also follows the style boolean 'c' rules of nonzero / zero, but the compiler will make fun of you
|
||||||
|
|
||||||
|
## null values
|
||||||
|
|
||||||
|
### *iglishmek* does not have null, it stole some monads from Rust and Haskell, they never saw it coming
|
||||||
|
|
||||||
|
If you are coming from haskell, a 'Just' is `< some value >` and a 'None' is `<>`, note 'None' is also an error
|
||||||
|
|
||||||
|
Like in Rust you have `unwrap` and `unwrap_or` and the like, you use `?` and `??`
|
||||||
|
|
||||||
|
```
|
||||||
|
a : <3>
|
||||||
|
b : <>
|
||||||
|
|
||||||
|
x : a?
|
||||||
|
y : b ?? 1
|
||||||
|
|
||||||
|
stdout.write("%d%d\n", x, y) ! outputs 3, 1
|
||||||
|
```
|
||||||
|
|
||||||
|
additionally, a None will be evaluated as "false" and Just as "true" in a boolean check
|
||||||
|
|
||||||
|
as you can see the `?` after the form notes that it is wrapped in a maybe
|
||||||
|
|
||||||
|
## any
|
||||||
|
|
||||||
|
any is the same as an Object in OOP languages, but is used slightly differently, it is mostly used for data structures like
|
||||||
|
|
||||||
|
```
|
||||||
|
let test any[] ! this is a list of form abstract
|
||||||
|
```
|
||||||
|
|
||||||
|
## error
|
||||||
|
|
||||||
|
error is a form which describes an error that occurred, it is similar to the Go programming language and is returned as a monad like the maybe monad above and is unwrapped in a similar way, take a look at the tunnel section for an example
|
||||||
|
|
||||||
|
## datastructures
|
||||||
|
|
||||||
|
### list
|
||||||
|
|
||||||
|
syntax
|
||||||
|
|
||||||
|
```
|
||||||
|
let «atom_token» as «form»[]
|
||||||
|
|
||||||
|
!or
|
||||||
|
|
||||||
|
«atom_token» : [val1, val2, ...]
|
||||||
|
```
|
||||||
|
|
||||||
|
### set
|
||||||
|
|
||||||
|
same as list except does not allow duplicates, allows set operations
|
||||||
|
|
||||||
|
n is the starting size of the set
|
||||||
|
|
||||||
|
```
|
||||||
|
let «atom_token» as «form»{}
|
||||||
|
|
||||||
|
!or
|
||||||
|
|
||||||
|
«atom_token» : {val1, val2, ...}
|
||||||
|
```
|
||||||
|
|
||||||
|
sets also have the following transforms associated with them
|
||||||
|
|
||||||
|
### map
|
||||||
|
|
||||||
|
a simple form to form storage
|
||||||
|
|
||||||
|
```
|
||||||
|
let «atom_token» as «form» ~> «form»
|
||||||
|
|
||||||
|
!or
|
||||||
|
|
||||||
|
«atom_token» : { "v1":1, "v2":2, ...}
|
||||||
|
```
|
||||||
|
|
||||||
|
### sorted map
|
||||||
|
|
||||||
|
same as map except they shall be sorted by the key
|
||||||
|
|
||||||
|
```
|
||||||
|
let «atom_token» as «form» -> «form»
|
||||||
|
|
||||||
|
! or
|
||||||
|
|
||||||
|
«atom_token» : { "v1":1, "v2":2, ...} as «form» -> «form»
|
||||||
|
```
|
||||||
|
|
||||||
|
note that sorted map has to be coerced
|
||||||
|
|
||||||
|
### tunnel
|
||||||
|
|
||||||
|
described in "tunnel" section
|
||||||
|
|
||||||
|
### uri
|
||||||
|
|
||||||
|
matching `` (backtics)
|
||||||
|
|
||||||
|
### Basic operators
|
||||||
|
|
||||||
|
The following is a list of global operators and their effect:
|
||||||
|
|
||||||
|
```
|
||||||
|
!
|
||||||
|
comment
|
||||||
|
!!
|
||||||
|
block comment (looks for another !! to close)
|
||||||
|
:
|
||||||
|
set operator
|
||||||
|
?
|
||||||
|
unwrap or none
|
||||||
|
??
|
||||||
|
unwrap or
|
||||||
|
\
|
||||||
|
lambda function
|
||||||
|
+
|
||||||
|
addition
|
||||||
|
-
|
||||||
|
subtraction
|
||||||
|
negation
|
||||||
|
*
|
||||||
|
multiplication
|
||||||
|
/
|
||||||
|
divisor
|
||||||
|
**
|
||||||
|
power
|
||||||
|
=
|
||||||
|
equals
|
||||||
|
<
|
||||||
|
less than
|
||||||
|
>
|
||||||
|
greater than
|
||||||
|
>=
|
||||||
|
greater than or equals
|
||||||
|
<=
|
||||||
|
less than or equals
|
||||||
|
~=
|
||||||
|
approximately equal to (to be used with floating point evaluation)
|
||||||
|
.
|
||||||
|
accessor
|
||||||
|
..
|
||||||
|
expander
|
||||||
|
(1..10) is the same as writing (1,2,3,4,5,6,7,8,9,10)
|
||||||
|
++
|
||||||
|
inline add 1
|
||||||
|
--
|
||||||
|
inline subtract 1
|
||||||
|
+=
|
||||||
|
inline add n
|
||||||
|
-=
|
||||||
|
inline subtract n
|
||||||
|
*=
|
||||||
|
inline multiply n
|
||||||
|
\=
|
||||||
|
inline divide n
|
||||||
|
**=
|
||||||
|
inline power n
|
||||||
|
```
|
||||||
|
|
||||||
|
### basic transforms
|
||||||
|
```
|
||||||
|
eq
|
||||||
|
equal to
|
||||||
|
ne
|
||||||
|
not equals to
|
||||||
|
mod
|
||||||
|
modulo
|
||||||
|
not
|
||||||
|
logical not
|
||||||
|
and
|
||||||
|
logical and
|
||||||
|
or
|
||||||
|
logical or
|
||||||
|
nor
|
||||||
|
logical nor
|
||||||
|
nand
|
||||||
|
logical nand
|
||||||
|
xor
|
||||||
|
logical xor
|
||||||
|
band
|
||||||
|
bitwise and
|
||||||
|
bor
|
||||||
|
bitwise or
|
||||||
|
bnor
|
||||||
|
bitwise nor
|
||||||
|
bxor
|
||||||
|
bitwise xor
|
||||||
|
```
|
||||||
|
|
||||||
|
### keywords
|
||||||
|
|
||||||
|
`is`
|
||||||
|
|
||||||
|
checks if a atom is of that form
|
||||||
|
```
|
||||||
|
«token» is i32
|
||||||
|
```
|
||||||
|
|
||||||
|
`as`
|
||||||
|
|
||||||
|
coerces a form as another form if possible
|
||||||
|
```
|
||||||
|
let «token» as i32
|
||||||
|
```
|
||||||
|
|
||||||
|
also useful for setting the form for values which could be ambiguous
|
||||||
|
```
|
||||||
|
«token» : 0 as u32
|
||||||
|
```
|
||||||
|
|
||||||
|
`impls`
|
||||||
|
|
||||||
|
checks if a atom's form, or a form impls another form
|
||||||
|
```
|
||||||
|
«token» impls Tunnel
|
||||||
|
```
|
||||||
|
|
||||||
|
|
||||||
|
## Atom
|
||||||
|
|
||||||
|
An atom is an invoked form.
|
||||||
|
For those of you coming from an object oriented language
|
||||||
|
this is similar to creating an object on the heap using "new" keyword or the like
|
||||||
|
|
||||||
|
Atoms persist in the universe until they are not needed.
|
||||||
|
Each atom has its own "process" with "socket like" i/o.
|
||||||
|
|
||||||
|
an atom can be created (in the universe) using the following syntax:
|
||||||
|
|
||||||
|
```
|
||||||
|
«atom_token» : «form»(«fields», …)
|
||||||
|
```
|
||||||
|
|
||||||
|
note: if the atom name is omitted, it will make the atom unaccessible! but it is allowed, this is usually useful in the "universe" namespace
|
||||||
|
|
||||||
|
## Tunnel
|
||||||
|
|
||||||
|
Represents a path to a file, url endpoint, other process endpoint (like a socket, etc.)
|
||||||
|
|
||||||
|
Tunnels are inspired by translators in gnu/hurd, plan9 9p protocol, and unix sockets
|
||||||
|
|
||||||
|
tunnels are invoked like atoms, but have scope like control flow end scope closes the tunnel
|
||||||
|
|
||||||
|
note the form must always be of a form which is "tunnel-able" i.e. Files, sockets, etc
|
||||||
|
|
||||||
|
### transforms for tunnels
|
||||||
|
|
||||||
|
`tunnel? : attach(tunnel_atom)` -> open communication
|
||||||
|
|
||||||
|
`success? : tunnel_atom.clunk()` -> close communication
|
||||||
|
|
||||||
|
`success? : tunnel_atom.flush()` -> cancels long operation and dumps whatever is in buffer
|
||||||
|
|
||||||
|
`success? : tunnel_atom.open(resource, mode)` -> opens a tunnel for doing operations on
|
||||||
|
|
||||||
|
`success? : tunnel_atom.create(resource)` -> creates the object from the database graph/file from file structure
|
||||||
|
|
||||||
|
`data? : tunnel_atom.read(resource)` -> reads from a tunnel
|
||||||
|
|
||||||
|
`success? : tunnel_atom.write(resource, data)` -> writes to a tunnel
|
||||||
|
|
||||||
|
`success? : tunnel_atom.remove(resource)` -> removes the object from the database graph/file from file structure
|
||||||
|
|
||||||
|
`stat_data? : tunnel_atom.stat(resource)` -> returns the status of the file/resource
|
||||||
|
|
||||||
|
`version? : tunnel_atom.version()` -> returns the version code for the connected tunnel
|
||||||
|
|
||||||
|
`success? : tunnel_atom.walk(path_or_endpoint)` -> moves around the filesystem or through the graph
|
||||||
|
|
||||||
|
```
|
||||||
|
let data as «some form»
|
||||||
|
endpoint : «tunnel-able form»(endpoint_str)
|
||||||
|
tunnel : endpoint.attach(user, auth)
|
||||||
|
tunnel.?open("\some\resource").?read(data)
|
||||||
|
std.write(data)
|
||||||
|
data.flush()
|
||||||
|
endpoint.clunk()
|
||||||
|
```
|
||||||
|
|
||||||
|
in "terminal mode" the default tunnel is std
|
||||||
|
|
||||||
|
in "web mode" the default tunnels are log, info, trace, warn, error, but note these are all special tunnels which only accept write commands
|
||||||
|
|
||||||
|
## Transforms
|
||||||
|
|
||||||
|
```
|
||||||
|
tf «transform_token» («form» «parameter», ...) «return_form», ... {
|
||||||
|
«instructions»
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
You can also create a lambda/closure form by using the syntax
|
||||||
|
|
||||||
|
```
|
||||||
|
\«form» «parameter», ... {
|
||||||
|
«instructions»
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
- Built in transforms
|
||||||
|
- sort
|
||||||
|
- filter
|
||||||
|
- trig functions
|
||||||
|
- calc functions
|
||||||
|
- statistical functions
|
||||||
|
|
||||||
|
## Control flow
|
||||||
|
|
||||||
|
### do
|
||||||
|
|
||||||
|
```
|
||||||
|
do «token» in «collection», +/-/iter { «body» }
|
||||||
|
```
|
||||||
|
|
||||||
|
iterates through each object in the collection setting it to token
|
||||||
|
|
||||||
|
```
|
||||||
|
do «boolean expression» { «body» }
|
||||||
|
```
|
||||||
|
|
||||||
|
loops until the expression is false
|
||||||
|
|
||||||
|
```
|
||||||
|
do { «body» }
|
||||||
|
```
|
||||||
|
|
||||||
|
loops infinitely until break or return
|
||||||
|
|
||||||
|
### match
|
||||||
|
|
||||||
|
```
|
||||||
|
match «token» {
|
||||||
|
'a' -> actionA
|
||||||
|
'x' -> actionX
|
||||||
|
'y'..'z' -> {
|
||||||
|
actionY
|
||||||
|
actionZ
|
||||||
|
}
|
||||||
|
someTransformOfTokensForm -> actionSomeTransform
|
||||||
|
\«token's form» t { t <= 5 and t > 0 } -> actionLambda
|
||||||
|
_ -> actionNoMatch
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
### exceptions
|
||||||
|
|
||||||
|
take a look at error's, but you can panic on an error like this:
|
||||||
|
|
||||||
|
```
|
||||||
|
panic("error message" as err)
|
||||||
|
panic(-3 as err)
|
||||||
|
panic(«some_error_token»)
|
||||||
|
```
|
||||||
|
|
||||||
|
## Localization
|
||||||
|
|
||||||
|
will look up the text of «token» in the linked .igkz file
|
||||||
|
|
||||||
|
```
|
||||||
|
&«token»
|
||||||
|
```
|
||||||
|
|
||||||
|
.igkz files are json like:
|
||||||
|
|
||||||
|
```
|
||||||
|
{
|
||||||
|
some_token {
|
||||||
|
localization_1 {
|
||||||
|
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
some_other_token {
|
||||||
|
localization_1 {
|
||||||
|
|
||||||
|
}
|
||||||
|
|
||||||
|
localization_2 {
|
||||||
|
|
||||||
|
}
|
||||||
|
}
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
## Libraries and “includes”
|
||||||
|
|
||||||
|
In most languages the include or use statements get libraries which link to other files and so on. This quickly gets confusing and so requires package managers and installers, etc.
|
||||||
|
The other way to do this would be to just specifically “name” the paths using a tunnel and import it. You can even use localization tokens to create config files.
|
||||||
|
Since everything is lazily compiled jit anyways it (in theory) doesn't hurt performance much
|
||||||
|
|
||||||
|
```
|
||||||
|
import `https://raw.githubusercontent.com/some_user/some_library/some_file.igk`
|
||||||
|
```
|
||||||
|
|
||||||
|
```
|
||||||
|
import `./some_local_file.igk`
|
||||||
|
```
|
||||||
|
|
||||||
|
## Universe
|
||||||
|
|
||||||
|
All forms and complications exist within the universe.
|
||||||
|
The universe can be thought of as the "global" namespace in an object oriented language or as the kernel for the "atom processes" to exist in.
|
||||||
|
a "main" space should be created that invokes the required startup atoms of the syntax.
|
||||||
|
in kOS this actually *is* the kernel layer
|
||||||
|
|
||||||
|
## GUI
|
||||||
|
|
||||||
|
The GUI is inspired by PicoLisp and Electron, using a web browser engine to render the GUI including 3D stuff like webgl.
|
||||||
|
Most html elements have an analogous form in *Iglishmêk*: Tables, lists, links, buttons, input boxes, etc.
|
||||||
|
In kOS these are replaces by its own version of these forms.
|
||||||
|
|
||||||
|
These of course can be wrapped in your own implementations. The idea is that on *Iglishmêks* side all UI is unified by forms but also is interoperable with HTML, templating engines, or gui libraries
|
||||||
|
|
||||||
|
```
|
||||||
|
ui Table impl HTML {
|
||||||
|
start = "<table>"
|
||||||
|
end = "</table>"
|
||||||
|
}
|
||||||
|
|
||||||
|
ui TableRow impl HTML {
|
||||||
|
start = "<th>"
|
||||||
|
end = "</th>"
|
||||||
|
}
|
||||||
|
|
||||||
|
ui TableColumn impl HTML {
|
||||||
|
start = "<td>"
|
||||||
|
end = "</td>"
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
## Concurrency
|
||||||
|
|
||||||
|
As in elixir there are as many schedulers as there are cores for your cpu
|
||||||
|
Like in CM and real time micro architecture systems like QNX tasks are scheduled based on priority and must stay within a time limit or it will be “punished” into a lower priority
|
||||||
|
Threading in *Iglishmêk* are split up into tasks (which take input) and daemons (which take no input)
|
||||||
|
Tasks are spawned whereas daemons are summoned
|
||||||
|
Message passing can be achieved by using tunnels.
|
||||||
|
|
||||||
|
probably should take concurrency stuff from golang; its very nice
|
||||||
|
|
||||||
|
|
||||||
|
## Testing
|
||||||
|
|
||||||
|
Tests are done inside of a `test` block
|
||||||
|
|
||||||
|
```
|
||||||
|
test some_test {
|
||||||
|
someTransform() -> true
|
||||||
|
|
||||||
|
|
||||||
|
}
|
||||||
|
|
||||||
|
```
|
||||||
|
|
||||||
|
### assertion
|
||||||
|
|
||||||
|
```
|
||||||
|
«error or none» : assert(«expression», «expected output»)
|
||||||
|
```
|
||||||
|
|
||||||
Loading…
Reference in New Issue