Re: New Programming Language: Salmon

On Nov 2, 9:37 pm, Kaz Kylheku <k...@kylheku.com> wrote:
> On 2011-11-02, Chris <ch...@chriswilson.info> wrote:
>
> > I've created a new general purpose programming language and a full
> > interpreter for it. I'm looking for early adopters to give it a try
> > and give feedback.
>
> I had a good look at your reference manual, etc.
>
> My honest opinion is that you've created a fairly uninteresting 'blub'
> language, with new syntax and terminology for doing pretty ordinary things.


I really appreciate that you took the time to do that, and that you
gave your honest opinion, even if it was that Salmon wasn't very
interesting to you.


> For instance:
>
> quarks: objects that enumerate and identify, such that two quarks are
> either equal or unequal. New term for "symbol", with limitations.
>
> tagalongs: your new term for "property lists" that can be attached to
objects,
> easily created with a couple of macros in Lisp and either weak hash tables
> or finalizations (non-ANSI, but common extensions) to build the assocation
> in a way that doesn't prevent garbage collection of unused objects.
> In about 15 minutes of coding, I can make myself the syntax which supports
> the following: ...


I think to some extent this comes down to the whole question of why
put any constructs at all in programming language, beyond a small
core. As long as you have a certain minimal expressiveness in a
language, any constructs you could add to the language could be
emulated on top of the small core sub-set of constructs. There is a
sizeable camp that loves lisp and sees it as preferable in nearly all
cases to build everything on a very small core of basic language
constructs.


Whether adding constructs is useful or not is really subjective. It
has a lot to do with how an individual programmer likes to think of
things and how the proposed construct maps to the way the programmer
thinks.


Putting constructs in the language itself can give the advantages of
syntax that can make it easier to read and compiler or interpreter
support for checking the constructs are used as intended and for
efficiently implementing them. It can also greatly aid readability by
providing a basic set of concepts that all readers of the code in a
language will be familiar with, and whose semantics they understand.


About tagalongs in particular, there are some ways that tagalongs work
in Salmon that are different than what you would get with your
implementation. In your implementation, all values that are equal
would have the same tagalong field for a given tagalong key, but in
Salmon that need not be the case. For example, in Salmon I could have
a function that returns the value 5 with a tagalong attached with
additional information that would be visible to those with the proper
key. On another call, it might also return 5 but with a different
field value for that same tagalong key, to convey additional
information that is different for that call. In your system, for a
particular tagalong key, 5 would always map to a single field value at
any given time.


Also, in Salmon you cannot iterate over all the tagalong key/value
pairs for a given object. This is deliberate. It's information
hiding in support of modularity. Modules that don't have access to a
particular tagalong key will never see it and never be able to tell
it's there. This is a specific instance of the trade-off between
introspection and information hiding to support modularity.


> You've bogged down tagalongs with the possiblity of static type
> declarations, which don't really add much value; they are just ways
> to make the language get in your way.


Whether adding type information to declarations adds value or gets in
the way seems to be a subjective point on which many people strongly
disagree. To me, adding type information is very helpful. It helps
me record some of my reasoning in an explicit and unambiguous way. It
helps me reason about the code later by knowing there are limitations
on what values will be where when. It helps me find bugs more quickly
because the language implementation will not let the type constraints
be violated, and will tell me if something would violate them.


> > I believe there's always room for new ideas,
>
> Why don't you introduce Salmon on Rosetta Code and try implementing
> a few of the tasks, so people can get some rough idea for how it stacks up
> against numerous other languages?
>
> In Rosetta, on the same page, people can see how a given task is solved in
> Python, Lisp, SNOBOL 4 (!), Visual Basic, Salmon, C++, you name it.


I think that's a very good idea. Thanks for the suggestion.


I do think that it's hard to show off all of Salmon's strengths with
code that does small tasks, though. I think one of the strengths of
Salmon is supporting both programming-in-the-small sorts of small
programs with a minimum of overhead but also supporting large, multi-
developer projects, where type information and modularity support
become very important. Unfortunately, it's hard to show off things
that matter most only for really large, complex software systems.


Again, thanks for the feedback.


                --Chris

Return to the comp.compilers page.
Search the comp.compilers archives again.