I think it's great that people create new languages. It's fun and a good learning exercise. For this language I'm very unclear on the scoping rules, and the dynamic environments look quite hard to reason about. I can't imagine ever using the language, but I'm pleased the creator is exploring some off beat ideas.
> Variables are not unique. You can declare multiple values for the same variable name using ":=" and append in the stack. If you want to edit the last declaration, just user simple "=" operator. To remove the last variable with specific name in stack, use "del varname"
Isn't this very confusing in almost all instances?
Forth behaves the same way. The vocabulary is really a stack, and you can define words, redefine them, and then pop them back off to return to the old value.
It's really not useful for variables, but can be very useful for functions, and since they're pretty much the same thing, you get the behavior for free. Although I haven't touched Lisp, my understanding is that Forth and Lisp have some conceptual similarities, but Forth is written by an engineer and Lisp by a computer scientist. Limit you for your own safety? Not a thing in Forth.
It being explicit/arbitrary makes it more confusing, not less. At least most languages with variable shadowing, there's a block of some sort that defines the scope. Here it'd just be anywhere that it can change meaning.
In block scoped languages, you cannot access variables outside of the scope. They disappear entirely when the scope terminates (exemplified by C and its ilk), or are captured in a closure (Lisp) possibly downward-funarg-only (Pascal) such that only the body of the closure can access them.
In this Kamby language, it looks like the bindings survive and are then accessible by name. When you're executing these [ ... ] blocks, a tree-shaped environment is built up which is then navigated with the :: operator, enabling it to simulate objects with fields.
The idea of there being a stack-like environment of variables which can survive the blocks in which they are bound is very useful in pattern matching and unification.
Under pattern matching, the successful path will have the cumulative variables arising from everything that has successfully matched, including some nested constructs. However, the search strategy will implicitly backtrack in searching for matches, and in backtracking, it will implicitly erase any variables accumulated in the discarded paths.
In the TXR pattern language, I invented some mechanisms for controlling the proliferation of variables. When a pattern function is used, only those variables that correspond to its arguments can emerge.
How it works is that the unbound variables x and y are identified with the arg1 and arg2 variables. The pattern function executes, binding arg1, arg2 and arg3. Then a resolution step is done at return-time. Because arg1 was identified with unbound x, x now receives that binding. Similar for y. The variable arg3 disappears; that entire local environment of the function is discarded, and x and y are grafted onto the original environment that existed on entry into the function.
If we bind an argument, the parameter will be bound on entry into the function, and so then has to unify in the subsequent bind directive. It does if we pass the value "a1":
The variable binding environment isn't reified as a value that can itself be bound as a variable and inspected; in any context, there is one environment which contains everything that was done in the chain of pattern matching leading up to that point; dead ends that were backtracked out of are gone.
How is this less confusing? := vs = will either push a new variable on top of a stack of identically named variables, or change the content of the top element on that stack? Why would anyone want any of that? Shadow variables are usually associated with hard-to-find-bugs, (i.e. forgetting that there is already a variable named 'xyz' in the current scope) not some great feature we want more of..
FWIW I think the author is trying to simulate let binding (or lambda binding, or both). But since there’s no syntactic scope you have to do your own stack management. Ugly and clunky. But this isn’t really a language intended to be used. It’s sort of like lisp assembly.
What is Kamby?
A small, embeddable and convenient language for who want to use and understand what is happening behind the scenes. The core is just ~400LOC and binary has just 20kb.
Hi! This looks super cool. I'm curious at what inspired you to implement variable stacking. At first I was like "whaaaaat", but then I thought, "maybe everything being a stack is useful?" Maybe for like immutable state or something.
By the way, I always wondered why not just take a lisp, put every single thing (even an operator) on a separate line and indent every level of parentheses with a space or two (4 spaces is too much - deep nesting would go too much to the right). So there would be no need for the parentheses in most cases.
This is a divisive question, because of survivorship bias. Remember when the WWII Brits wanted to reinforce planes where they saw bullet holes coming back, till a statistician asked why no planes came back with holes in the other spots?
People who use lisp like the parentheses.
I don't, though they're no more objectionable than all the {}; languages. I just don't like unnecessary punctuation.
I coded in scheme for years using a preprocessor that understood
define-syntax opt
syntax-rules |
$ _ (x v) b ...
let || x | if (null? x) v | car x
b ...
which is line for line equivalent to
(define-syntax opt
(syntax-rules ()
((_ (x v) b ...)
(let ((x (if (null? x) v (car x))))
b ...) )))
It's a matter of taste, but I'd rather read the former. The key ideas, other than using indentation to carry parenthesis level, are to use $ to hang double indents, and | to open a parenthesis that auto-closes.
I gave this up learning Clojure so I could use other people's tools. Instead I prefer lighter parentheses, and I use this script to tailor fonts for coding lisp:
I have the most trouble with comment characters, in any language. In various languages I used a preprocessor that implemented a practical version of "comments are flush, code is indented" (hey, it cost me one level) and relied on syntax coloring to mute the comments. Again, I gave this up to use other people's tools.
If you learn Lisp, both the language and the tooling, you'll come to really like the parens. I suggest to everyone who uses Lisp, just set your editor's syntax highlighter to make the parentheses fade into the background color almost completely. They're still there, for correctness, structured editing, and ease of sharing with others; but they don't stand out.
A technical reason not to do that is that if you have the parentheses and the indentation then you have the structure encoded in two ways. This is useful; if the two differ, that indicates a problem.
Another technical reason is that we work with text based version control tools, under which we use whitespace-insensitive diff as a hack to hide some differences that don't make a difference. That tool becomes unreliable over indentation-only languages; you can make a semantic change whose whitespace-insensitive diff is empty.
Another technical reason not to go indentation-only is that you don't know whether a partially obscured block of code is complete or just a prefix:
What would this accomplish aside from spreading your code all over the screen, making it both hard to read and edit, and reducing your freedom of formatting for semantic sense?
I wish someone would reinvent Rebol/Red with understandable scoping rules. One of the few reasons I don't use the language is because the scoping/binding rules are just completely inscrutable.
Browsing the source code, I came across something completely unexpected. I didn't know you could put code in structs like this sample from kamby/kamby.c
Is this legal? If so, I'm going to use the heck out of it for my version of STOIC.
[Edit] Ok.. thanks for the help.. I'm used to seeing function types declared AFTER the parameters because pascal habits die hard. It looked like a run of the mill structure declaration to me.
I don't do a lot of C, but isn't this just a global function returning a pointer to a KaNode? If I remember correctly this is just Cs way of specifying a type is a struct same thing with the line in your example "struct KaNode *output = ..." someone feel free to correct me if I am wrong though.
That’s a function that returns a struct. In C structs live in their own namespace and references to them have to use the struct keyword unless you define a typedef.
If it makes you feel any better, I can't remember the last time I saw that construction in the wild. Idiomatic C codebases use a typedef for this 10 times out of 10.
I can feel that this is surely a fun project, full of decent tricks on the code level. Still, tricks are just tricks, and won't provide firm foundation. It's gonna be difficult to engineer either an application or the language itself in the current state. I kinda wonder what OP is planning after this.
It’s not actually s-expressions but the front page gives you a pretty clear reader algorithm. The macros are sitting right there waiting to be brought.
Lisp code tends to have fewer delimiting punctuation characters than most algol style current languages. I think people tend to dislike languages that have only the minimum necessary, because it's easy to misread code then and redundancy helps compilers catch mistakes as inconsistent syntax.
I never understand these complaints about parenthesis, my editor takes care of them. Interestingly people never complain about the inconsequences in mathematical notation, i.e. infix operators like plus or minus (e.g. 3+5), postfix operators like faculty (i.e. 9!) and last but not least prefixed user defined funtions like f(x).
But as Lisp was my first real language, I might be a bit biased. And besides Lisp I like languages like Forth or Postscript, and even Perl ;-)
What editor takes care of your parentheses? I haven't found anything quite painless enough for me to want to dive into all that punctuation. Are you talking about paredit? Parinfer? Something else?
It’s not about writing but about readability. Clojure is easier to read than Scheme because it uses more punctuation (brackets and braces instead of only parens.
There’s a point in using different signs that mean different things.
