
Szl, a Tcl-inspired embeddable language - dimkr1
https://github.com/dimkr/szl
======
no_protocol
This 3-letter name is already taken [0], might be worth at least considering a
different one.

It looks like this probably qualifies as a Show HN as well, if you can edit
the title.

What are your future plans for the project? Are you using it regularly?

[0] [https://github.com/google/szl](https://github.com/google/szl)

~~~
thesmallestcat
If Google can reuse names like "Go" and "Dart," then their "szl" is fair game
for reuse.

~~~
spotman
Fair game sure, but unfortunately confusing. If there was another dart that
was an actual programming language ( Is there ? ) you would have to qualify
every time which dart programming language you meant. I imagine searching for
things online would be tricky.

~~~
munificent
> f there was another dart that was an actual programming language ( Is there
> ? )

I don't believe so. We changed the name to "Dart" from "Dash" because the
lawyers did a trademark search and felt the former was a safer bet.

------
qznc
The language manual: [http://dimakrasner.com/szl](http://dimakrasner.com/szl)

~~~
no_protocol
The writing in here looks pretty clean. My one suggestion would be to get some
more examples in there. Most of the descriptions are one line and as a total
outsider I just wanted to see some in action.

This document is much more appealing to me than the project's README. Since
people often browse just the README when visiting a repository on GitHub, I
wonder if you would be better off getting some of the language from sections 1
and 2 into the top of your README. The current README Overview just didn't do
it for me. As soon as I saw the first two sections of the user manual, I was
more interested because it showed what problem you were solving and how.

> Warning - This manual may reflect a future state of szl.

Got a chuckle out of me.

------
ufo
Why does every command start with a "$"?

~~~
dimkr1
Because everything is an object, including built-in functions

~~~
nowayyeah
Then why the $, you already know that it's an object.

~~~
dimkr1
Nope. The first token in a statement is treated the same way as those that
come after it. This way, you can do stuff like this (i.e. imagine a dictionary
that maps HTTP methods to hander functions):

    
    
        >>> $local functions [$list.new $puts $sleep]
        puts sleep
        >>> [$list.index $functions 0] hello
        hello

~~~
ufo
I think it might be better to special case the first word in the command, just
like sh and tcl do. The list.index case you mentioned is much rarer than just
calling a command directly.

------
qznc
I cannot find the actual differences to Tcl?

~~~
dimkr1
It isn't Tcl, but a language inspired by Tcl. I think the manual tells the
difference, once you see the more restricted syntax.

------
catuskoti
Fundamentally it is more like tcl (function chaining) than like bash (process
chaining), where process pipelining is the central operation, and where
functions and programs are equivalent. In that sense, it has mostly the
advantages but also the inconveniences of tcl, javascript and similar non-
shell scripting languages. My opinion is that they have quite missed the ball
in bash on non-nestable arrays when they introduced them quite recently, but
besides that, bash is still pretty much my favourite tool.

~~~
chubot
Yes, in writing my bash parser/interpreter (see below) I explored the non-
nested arrays and assoc arrays issue.

I think it mainly has to do with the fact that bash has no references and
garbage collection. When you create an array like [1, 2, [a, b]] in
Python/Ruby/Perl, you are introducing the concept of references, as well
introducing hte potential for reference cycles.

In contrast, an array in bash is just a value, and it took me awhile to figure
out how to even copy it. None of these work:

    
    
        a=('x y' z)
    
        b=${a}
        b=${a[*]}
        b=${a[@]}
    
        b="${a[*]}"
        b="${a[@]}"
    
        b=( ${a} )
        b=( ${a[*]} )
        b=( ${a[@]} )
    
        b=( "${a}" )
        b=( "${a[*]}" )
    

This works:

    
    
        b=( "${a[@]}" )
    

In other words, it takes 11 characters to properly copy an array! This syntax
is horrible.

~~~
jstimpfle
What's more horrible about it is that the simpler sh constructs are somehow
not respected in bash culture.

In sh, each function has a local array, and you use that array with _" $@"_.
And typically you can get along with only that array. Not so bad.

    
    
        my_b() {
            somefunc foo "$@" bar
        }

