
Scopes – Retargetable programming language and infrastructure - homarp
https://bitbucket.org/duangle/scopes/wiki/Home
======
anaguib
For some reason I read it as regrettable programming language and
infrastructure

~~~
manifestsilence
Haha, I read it as rechargeable. I hoped that meant that it would somehow
inject new functionality to avoid the ravages of time and not eventually be
looked at like Cobol is.

------
giornogiovanna
The introduction mentions "view propagation", which does borrow checking
without annotations. Is this documented anywhere?

Also, I wish more languages had homepages like the Go one[0]. It takes a lot
of reading to get to the point where you can see some non-trivial code[1],
which is frustrating.

[0]: [https://golang.org](https://golang.org)

[1]:
[https://scopes.readthedocs.io/en/latest/tutorial.html#a-mild...](https://scopes.readthedocs.io/en/latest/tutorial.html#a-mild-
breeze-of-programming)

~~~
Rusky
There's no technical reason the Rust borrow checker couldn't run without
annotations either- that's a design choice, similar to the way Rust requires
function types even though it could infer them. It makes inter-function
contracts clearer, which improves error messages, and avoid the need for
whole-program analysis.

I couldn't find anything more about "view propagation" either but I strongly
suspect it's no more powerful. Probably less and/or buggier at this point,
given its relative maturity.

~~~
giornogiovanna
But how would you distinguish between

struct A<'a, 'b>(&'a u8, &'b u8);

and

struct B<'a>(&'a u8, &'a u8);

without lifetime annotations?

~~~
sanxiyn
You can always assume the former(all lifetimes are different). It is strictly
more general.

~~~
giornogiovanna
Thanks, so lifetimes can definitely be inferred for safe code (although just
like type inference, they can lead to leaky abstractions). But aren't lifetime
annotations necessary for unsafe code? How could you cast a pointer into a
struct into a raw pointer and back, while preserving the lifetime, without
them?

------
buovjaga
Devlog for Scopes and the game it was created for (NOWHERE alien life
simulator):
[https://lritterdevlog.hashbase.io/](https://lritterdevlog.hashbase.io/)

------
Confusion
What I would be very interested in seeing in an introduction to a new language
is an explanation of why the authors think other languages that intend to
support a similar combination of features have failed to achieve that or have
failed to get traction.

These kinds of introductions always read like "we're going to combine these
and these and these awesome features from all your favorite languages" and
well, what's not to like? Wouldn't everyone want this? So I can't help but
wonder: why didn't anyone previously succeed at creating such a language? What
are you going to do differently?

~~~
sanxiyn
This answer will not satisfy you, but I can answer this as someone who worked
on design and implementation of multiple programming languages: Q. why didn't
anyone previously succeed? A. Nobody tried.

There are a LOT of decisions that go into design and implementation of
programming languages. Due to combinatorial explosion, vast majority of
combination was never tried. This is still true even after you group "similar"
combinations. But usual standard of similarity used by many people is "How is
Rust different from Go?", which is too laughable to answer. To me, Scopes
seems different enough that the author should not feel any need to answer
questions like yours.

~~~
nickpsecurity
I'll add to your answer that a lot of them aren't production-worthy either.
That might be the packaging, lacking a standard library, not integrating with
whatever is dominant in that space, no docs on basic usage, and so on. This
happens with verification tools in CompSci, too.

So, they need to get a combination of features to whatever is the minimum of
usability the target audience expects. I also push for it to integrate well
with legacy libraries with no overhead. Scope author is doing that for C
libraries. As a side effect, it's a big boost on productivity since people can
always lean on whatever libraries are already there.

~~~
dTal
I was gonna say - I already have a language with the expressivity of Scheme,
the convenience of Python, and the performance of C - it's called "Chez
Scheme". Why isn't it popular? Because A) the performant implementation was
proprietary until relatively recently, and B) it's less "batteries included"
and more "that drawer in your house full of batteries, most of which are
dead". There's a _great_ language in there, but it lacks the tooling and
social structures for popularity.

~~~
nickpsecurity
Racket is being ported to Chez Scheme. That might solve the batteries included
problem at least at the Racket level. However, if you don't like Racket, then
I don't know if it will do anything since using Racket's libraries in Chez
might be too kludgy to attempt.

[https://blog.racket-lang.org/2019/01/racket-on-chez-
status.h...](https://blog.racket-lang.org/2019/01/racket-on-chez-status.html)

Since you're a Chez fan, I'll also throw in its historical overview in case
you missed it. That they had Scheme on 8-bitters really tripped me out.
Talented team.

[https://www.cs.indiana.edu/~dyb/pubs/hocs.pdf](https://www.cs.indiana.edu/~dyb/pubs/hocs.pdf)

------
CharlesMerriam2
The bar for a new programming language is higher than ten years ago.

Introducing a language should now include "What are the cool new things in
this language?" The short list where this shines, e.g., "Go - compiles really
fast and no classes". "Rust - deep safety and a novel macro system". "Python -
Batteries included and easy to write."

A language also needs to include some design philosophies. Sometimes its
simple: "DRY"; sometimes its the tradeoffs ordered in Zen of Python. You need
to say something.

So, what's this new language do again?

~~~
mehrdadn
> Introducing a language should now include "What are the cool new things in
> this language?"

From their page:

\- Aims to combine the expressivity of Scheme with the convenience of Python,
Lua or Javascript and the performance of C.

\- Compile-time resource management using view propagation, an annotation-free
variation of borrow checking.

\- Support for live code execution as well as offline compilation of object
files.

\- Statically typed but fully inferred type system via forward propagation.
Supports closures as zero-cost abstraction.

etc.

I don't know how tough the crowd is nowadays but I was already sold when I
read the 1st and 2nd items above.

~~~
jerf
With no direct disrespect intended towards these authors in particular, I'll
believe "expressivity of Scheme with the convenience of Python, Lua or
Javascript and the performance of C" when I see it. Goals aren't results. I've
seen that goal a lot. Given how often I've seen it, and how I'm yet to see a
result that matches it, I'm coming around to the assumption that that set of
goals is probably just not possible. (I suspect Python, Javascript, etc. are
fundamentally, in their very core, based on some operations and conveniences
that are just fundamentally going to be slow on modern processors. The only
way around it is to drop some of the conveniences. _That_ I have seen be
successful.)

On the "goals aren't results" front, the second one is also one that I'd want
to see how it plays out a bit more before getting too excited; it's also
possible that it may not be possible at it currently exists in the author's
heads.

------
jonathanstrange
Out of curiosity, the docs state that closures are supported as zero-cost
abstractions. That seems to imply that the language can store environments at
zero cost. How is that possible?

~~~
sanxiyn
It does not imply that. Closures are usually implemented with environments,
but this is unnecessary. You can compile so that everything that would be in
the environment is passed as arguments. It seems to me Scopes is implemented
this way.

------
mehrdadn
This looks awesome. Sadly when I try to run it on Windows I get:

    
    
      error: execution engine failed: The file was not recognized as a valid object file
    

Anybody have any idea what's up?

~~~
mehrdadn
Update: It seems this happens if the directory that contains the bin\
directory is named "Scopes".

------
mehrdadn
Has anybody managed to figure out how to use compile-object to produce
executables?

~~~
mehrdadn
Update: I found a demo in their source code in testing/test_object.sc which
you can apparently compile to a nice and tiny ~16 KiB executable via:

    
    
      scopes test_object.sc && clang -O3 -s -o test.exe test.o

~~~
jacereda
On Mac it's a bit less (8k) and size reports:

    
    
       text    data     bss     dec     hex filename
        172      24      44     240      f0

------
protomyth
Is there some downloadable documentation?

~~~
adamfeldman
[https://buildmedia.readthedocs.org/media/pdf/scopes/latest/s...](https://buildmedia.readthedocs.org/media/pdf/scopes/latest/scopes.pdf)

Accessible through this page via the hamburger menu > click “Read the docs”:

[https://scopes.readthedocs.io/en/latest/](https://scopes.readthedocs.io/en/latest/)

------
_bxg1
What distinguishes it from Rust and Swift?

~~~
panic
There are lots of differences, but a big one is its lack of a strong
distinction between compile time and run time. From "Scopes for C/C++ Users"
([https://scopes.readthedocs.io/en/latest/cpp_users.html](https://scopes.readthedocs.io/en/latest/cpp_users.html)):

 _> C/C++ requires programs to be built and linked before they can be
executed. For this, a build system is typically employed._

 _> In contrast, Scopes’ primary execution mode is live, which means that the
compiler remains on-line while the program is running, permitting to compile
additional functions on demand, and to use other services provided by the
Scopes runtime library._

~~~
seanmcdirmid
Is that really a good use of the word live? Sounds like this is just hot
loading, not even hot reloading.

~~~
manch23
Sounds more like a JIT to me.

