On 7/13/2021 7:42 PM, Ivan Godard wrote:
> On 7/13/2021 9:40 AM, BGB wrote:
>> On 7/13/2021 3:03 AM, George Neuner wrote:
>>> On Mon, 12 Jul 2021 12:39:14 -0700, Stephen Fuld
>>> <sfuld@alumni.cmu.edu.invalid> wrote:
>>>
>>>> I had heard of Racket, but didn't know anything about it, so I did a
>>>> little reading.
>>>>
>>>> I think the issue to which you are referring is that Racket comes from
>>>> the Lisp, Scheme family of languages, this has more parentheses and
>>>> uses
>>>> prefix notation when compared to the Fortran/C type syntax.
>>>>
>>>> For the record, my undergraduate degree was in Chemistry, so I have
>>>> some
>>>> sympathy for the scientists/engineers.
>>>>
>>>> Without deprecating Racket in any way (I don't know enough to do that),
>>>> I disagree with you and agree with the "too many parentheses/prefix
>>>> notation" people.
>>>>
>>>> These people are not computer scientists, and while they are usually
>>>> smart people, they want to get some job in science/engineering done,
>>>> and
>>>> want the easiest tool to use to do that.  They don't particularly care
>>>> about some arcane aspects of the language they are using.
>>>>
>>>> They are familiar with formulas.  They use them all the time in their
>>>> classes and in their work.  Remember, Fortran is short for Formula
>>>> Translator.  So a language that is similar to that is easier for
>>>> them to
>>>> learn, thus a better choice.  In that context, I don't regard their
>>>> disdain for Lisp style language syntax as "nonsense".  They want to do
>>>> some job and not be distracted by unfamiliar syntax, etc.
>>>>
>>>> Thus I think Python is a good choice (not counting the 2-3 mess).
>>>
>>> A little off-topic, but ...
>>>
>>> Python is great for scripting - but I do /not/ think it is great for
>>> application programming.  Particularly for science or engineering.
>>>
>>> One of the biggest tells is that most of its data processing libraries
>>> are written in C - not in Python.  Whether simply for performance, or
>>> for the inability of the language to express the solution, many people
>>> have decided to bypass the language.
>>>
>>> So what happens when there is no library for what you want to do.  Can
>>> you express your solution in Python?  Yeah, probably ... but will it
>>> perform well enough when you point it at large amounts of data?
>>> Probably not.
>>>
>>
>> Python performance tends to be relatively poor, even among dynamic
>> languages, from what I have seen...
>>
>>
>>>
>>>
>>> In contrast, most of Racket's libraries are written in Racket.  In
>>> fact, most of Racket is written in Racket - there is only a small
>>> bootstrap core that still is C/asm.
>>>
>>> There is a portable bytecode interpreter, but on most platforms Racket
>>> applications are compiled: either JIT (long time), or in more recent
>>> versions with an AOT compiler.
>>>
>>> No disputing, Racket has a steeper learning curve than Python - but if
>>> there is no existing code that does what you want, you probably can
>>> write it in Racket and /still/ get good performance without dropping
>>> into a different langauge (which you can, Racket has a full featured
>>> FFI if you need it).
>>>
>>> And if you don't like the default Lisp/Scheme-like syntax or behavior,
>>> Racket is a perfect transpile target for DSLs.  Racket provides a YACC
>>> work-alike, and a number of other parsers (LL and LR) are available as
>>> libraries.  You can create a language using any syntax you like.
>>> Transpiled languages can be freely intermixed in the same program.
>>>
>>> There are a number of such DSLs already: Prolog, Java, Algol-60, ML,
>>> even Python [though I don't know which version or how complete it is].
>>> And many others.
>>>
>>
>> Using a Scheme variant as a transpile target actually works reasonably
>> well. Writing code in it directly is usually less enjoyable though,
>> unless one is using the language in a way which can leverage its
>> features.
>>
>>
>> It does suffer an disadvantage in that the syntax hinders putting in
>> various types of side-channel metadata, such as things like source
>> file and line number information, ... It also doesn't deal as well
>> with structures where a lot of members may be optional.
>>
>> And, by the time one addresses the above issue, it has lost most of
>> what advantage it would have had over a more flexible format.
>>
>>
>>>
>>>
>>> For all that, Racket's developers are concerned that Lisp and/or
>>> Scheme has negative connotations and that people will avoid trying
>>> Racket simply because of the relationship.  They are seriously
>>> considering creating a new language, with similar features but with an
>>> infix syntax, and deprecating the existing prefix/sexpr syntax.
>>>
>>> The problem is, this (IMO bad) idea has been tried before:  Lisp
>>> itself was intended to have an infix syntax, but McCarthy backed off
>>> when existing Lisp programmers balked at using it.  Apple's Dylan
>>> language had a lot to offer, but died tragically when it changed from
>>> a Scheme-like to an Algol-like syntax.
>>>
>>
>> It is a tradeoff.
>>
>> A more traditional syntax is generally easier to work with, but
>> granted a lot of Lisp style features will not work nearly as well with
>> a different syntax.
>>
>> One of the main things it has going for it is the ability to work with
>> S-Expressions as data and then eval them or similar, or use them as
>> part of a procedural macro system, but this ability is quickly lost,
>> and doesn't map out nearly as well to a more opaque AST format.
>>
>>
>> This means that in a language with a more conventional syntax, an eval
>> mechanism generally needs to work with strings, and then often ends up
>> restricted (frequently a target of exploits; some of the major
>> use-cases for eval often adding glaring security holes).
>>
>> In statically compiled versions of a language, eval is often either
>> unavailable, or operates within an interpreter with its own
>> environment often separate from that of the parent.
>>
>> ...
>>
>>
>> One could, in theory, have a language which uses a more familiar
>> syntax natively, but then switches over to a Lisp style syntax for
>> metaprogramming and eval, but this would be kinda wonky and weird.
>
> Here's one vote for SmallTalk.
>

Hmm...

Early on, design for my scripting language was also influenced by Self,
which was itself a Smalltalk variant.

I hadn't been a huge fan of Smalltalk syntax, but it did influence a few
minor things in my languages.

Well, as noted, Scheme, Common Lisp, and Erlang had also been design
influences, along with C and JavaScript.

Initially, the Self influence took the form of a delegation feature,
where object fields named in a certain way would delegate to other
objects (IIRC, "foo" was a normal field, but "_foo" would delegate).

In slightly later versions (BS 1.5), this naming trick was replaced by
the use of a 'delegate' keyword, and 'self' was replaced with 'this'.
The 'this' variable was itself defined in terms of a delegate variable
(albeit was special in the VM); and "packages" were also originally
themselves defined in terms of objects and delegation.

In effect, the environment was composed of an interconnected mesh of
dictionary objects (generally with a hash-table used to cache lookups;
and a mechanism to flush the hash table, flush the contents of the JIT,
...., if one of these paths was modified after it had been traversed).
There was also a mechanism to avoid recursing into an object which has
already been visited during the search (the graphs were allowed to be
cyclic).

Meanwhile, JavaScript had used a more limited system where objects could
only have a single 'prototype' field which had this property, and they
didn't really apply it to anything else in the language. Likewise, JS
had used a simpler/plain lexical-scoping model.

In BGBScript 1.x, the types of scoping levels were:
global scope: graph of objects with delegate links;
dynamic scope: variables whose identity depends on control flow.
TLS variables can be seen as a limited subset of dynamic scope.
'this' scope: variables visible via 'this'
Defined as a delegate variable within the dynamic scope.
lexical: scope depends on relation between code-blocks.
Used within functions and for lambdas.

In my languages, the declaration of a dynamic scoped variable still
needed to be visible via the global or package scope to be able to
access it. Delegation could be applied within any of the above scope
levels to form links into other spaces.

I later (in the BS2 redesign) restricted to normally only apply to
static visibility (with a partial exception for dynamic objects, *), and
moved over to a slightly more conventional scope model, as this was a
lot less painful for the compiler and was easier to optimize.

*: Static paths will always be used in preference to dynamic paths, and
a dynamic path may not modify a variable visible via a static path.

In this case, the BS2 scope model is more like:
global/toplevel scope;
Behaves like the toplevel scope in C.
package / namespace scope;
Static visibility only, immutable at runtime.
dynamic scope;
Implementation overlaps with TLS variables;
'this' / class/instance scope (treated as intrinsic in BS2);
function/method block scope;
local lexical scope (subset of block scope, exists for lambdas).

For BS2, I had also restricted lexical scope to be by-value rather than
by-reference. In this case, a lambda would only capture the values held
in the parent frame at the time the lambda is created, however,
assigning to these captured bindings will have no effect on the parent
(and the parent scope may be destroyed independent of any lambdas
derived from it).

The change in scope model also changed the behavior of package/import.

BS 1.x: Package created a new object, which would contain the newly
declared members; import ("delegate import") could create a delegation
link within the package, which was visible to all parties. Importing a
package which imported another package would, implicitly, import both
packages. Import could also be done via the lexical scope, in which case
it would be private.

BS 2: Package is handled as a naming trick, so nothing exists at runtime
to "hold" the declarations. Likewise, "import" exists implicitly as part
of the lexical scope, so one party will not "see" packages imported by
another party (or "delegate import" semantics were not retained in BS2).

The traditional C scoping model can be seen as a lot simpler:
global toplevel;
function block scope.

Or, C++:
global/namespace;
'this' scope;
function block scope.
(Do C++ lambdas count as a new scope level?...).

TLS variables may exist, but are generally treated as a special case of
the global scope in C. Meanwhile, no other major C family languages I am
aware of are able to use dynamic scoping.

Though, as noted, doing a re-implementation of my BS2 language on top of
BGBCC and BJX2 is kind-of an uphill battle (and the language wont be
exactly the same as it was with the prior implementation).

Whether it is "worth it" is arguably fairly debatable though.

....