lxsameer
/
lxhome
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Some final touches on simple version has been made

This commit is contained in:
Sameer Rahmani 2020-01-04 13:44:28 +00:00
parent 7dd3bfc6d8
commit 7e55aa7476
1 changed files with 21 additions and 21 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

42
_posts/2020-01-03-serene-simple-version.md
View File

@ -9,25 +9,25 @@ theme: dark
As you might already know I'm working on [my own programming language ](programming/my-new-programming-language/)
for a while now. I'm still on early stages and I'm working on
[choosing the right platform](/programming/choosing-the-target-platform/)
for [#Serence](https://social.lxsameer.com/tags/Serene) and
I'm trying spend time on enough research and make decision based
for [#Serence](https://social.lxsameer.com/tags/Serene) and trying
to spend time on doing enough research and make decision based
on facts, scientific papers and collected data from experiments
rather than rushing into things and end up with a mess.
I believe those languages that take their time and move slowly
but with great research, plan and design are more successful in
the long term (Thanks to **Pouya** for pointing it out). Take **Clojure**
as an example. They are taking their time experimenting and validating
their hypothesis. As the result, Clojure is a well designed, stable
their hypothesis. As a result, Clojure is a well designed, stable
and highly backward compatible language with amazing productivity
pace. However, some other languages like Python are extremely
popular and consequently has more contributors. Dealing with all
those contributors caused Python to move faster than should. As a
result they ended up with some bad choices and horrible designs that
fixing them requires a humongous effort. Little by little, it becomes
those contributors caused Python to move faster than it should and
they ended up with some bad choices and horrible designs that
fixing them requires an humongous effort. Little by little, it becomes
harder and harder to fix those and move away from them. GIL is a good example,
instead of fixing the issue and removing GIL they are introducing
[something else](https://lwn.net/Articles/754162/) that might become
an other problem to fix the original one. In order to avoid these kind
instead of fixing the issue and removing the GIL, they are introducing
[something else](https://lwn.net/Articles/754162/) to fix the original
problem but it might become a pain point itself. In order to avoid these kind
of problem as much as possible I'm trying to take my time and do as
many as experiments that I need.
@ -41,9 +41,9 @@ I'll update the experiment files accordingly at the
repository.
I spend several days and implemented the pure java version. There repository
of the simple version is available in [gitlab repo](https://gitlab.com/serene-lang/simple-version).
I didn't paid too much attention to the details and created a very simple lisp
that follows the specification below.
of the simple version is available in the [gitlab repo](https://gitlab.com/serene-lang/simple-version).
This version is a dumb but good enough lisp that I didn't paid too much attention
to the details and created a very simple lisp which follows the specification below.
> Node: In this post where ever I use the name **Serene** for the implementation,
> I'm referring to the simple version.
@ -66,8 +66,8 @@ structures directly.
Instead of using a parser generator or a sophisticated parser, I just created
a simple read ahead position based parser that reads two chars and call the
appropriate method to create the corresponding `Node`. the `serene.simple.Node`
is an abstract class which has just one important method, `eval`. The whole
purpose of the reader is to parse code and create an AST like data structure
is an abstract class that has just one important method, `eval`. The whole
purpose of the reader is to parse the code and create an AST like data structure
which each node extends the `Node` class (I should've create the interface for
it but too lazy to change it now). The `eval` method of `ListNode` is a bit
special. It calls the `eval` method on all the elements on the list
@ -78,13 +78,13 @@ The `eval` method of `ListNode` contains more details regarding to java
interop as well which I leave it out of this blog post.
## Scope
Scope are simply a mapping between symbol names and values. There are two
Scope are simply a mapping between symbol names and values. Serene consists of two
different scopes, both implemented `serene.simple.IScope` and extends
`serene.simple.AScope` abstract class that contains the logic for symbol
lookup and insertion. These two classes are `serene.simple.Scope` which
is the general scope and it has a parent/child type of relationship with
other instances of the same class or `serene.simple.RootScope` which is
the top level scope. Beside that `RootScope` is pre-populated with all
other instances of the same class or `serene.simple.RootScope` that is
the top level scope. Beside that, `RootScope` is pre-populated with all
the builtin functions and types.
## Special forms
@ -92,7 +92,7 @@ Serene's [special forms](https://courses.cs.northwestern.edu/325/readings/specia
are pretty limited. All of them all classes which extend `serene.simple.SpecialForm`
abstract class and inherit from `Node` indirectly. The difference between
special form evaluation and function evaluation is that in case of special forms
Serene does not evaluate the arguments and leave the evaluation to the special form
Serene does not evaluate the arguments and leaves the evaluation to the special form
itself. Here is the list of Serene's special forms:
`def`: Creates a binding between a symbol name and the given value:
@ -230,13 +230,13 @@ Here is an example program in Serene simple version (`benchmarks/fib.srns` in th
## What is missing ?
Since Serene (simple) is an experimental language and I'll abandon it eventually,
I didn't bother with details and tried to get to the point as soon as possible.
Since Serene (simple) is an experimental language and I'll abandon it eventually.
I didn't want to go into a rabbit hole and tried to get to the point as soon as possible.
So I sacrificed lots of details. Here is a list of the most important missing
details:
* A namespace functionality. Because creating and compiling dynamic classes
is a rabbit hole and tons of work which doesn't make sense for a toy
is a massive task and needs tons of work which doesn't make sense for a toy
project.
* Unified function interface.
* Requiring different namespaces