The Scopes Programming Language • Hacker News Board

Re: The Scopes Programming Language

#21

Post by paniq303 » Sat, Mar 17, 2018, 3:25 PM UTC

tom_mellior wrote: post #16

yorwba wrote: post #13

Earlier quoted context omitted.

It has a REPL, supports S-expressions as a special case of the syntax, has garbage collection[1] and doesn't appear to have more C-ish semantics than Scheme already has. [1] https://github.com/duangle/scopes/commit/13255e0ae7ab76e070c...

That code does indeed automatically delete some entries from some collection, and it does use garbage collection terminology, but it doesn't appear to be full garbage collection for the whole language. Hard to tell in the complete absence of comments and a commit message. But http://scopes.readthedocs.io/en/latest/about.html says "The memory model is compatible to C/C++ and utilizes simple unmanaged stack and heap me…

> That code does indeed automatically delete some entries from some collection, and it does use garbage collection terminology, but it doesn't appear to be full garbage collection for the whole language. Hard to tell in the complete absence of comments and a commit message.

It's very old code from two years ago, when the language was still being prototyped. I did have a form of GC for a while that I threw away again because I couldn't make it work right.

I recommend not taking any commits before the first tagged release seriously.

> Fortunately, it doesn't look like he ever tried it.

I tried, but I'm completely paralyzed here. As long as I can't see a straightforward way to integrate support into the typechecker, I won't write a single line.

Also, why "fortunately"?

> as if the developer did think of these as opposites

Not opposites, just not aligned with each other. The demands of Scheme's runtime model inherently conflict with realtime performance. There's nothing wrong with that, but that sets it apart from C.

With this sentence, I hoped to address Scheme users who wish they could generate faster, tightly-constrained assembly while not having to give up on hygienic macros and nested evaluation contexts. No insult was intended.

Re: The Scopes Programming Language

#22

Post by childintime » Sat, Mar 17, 2018, 5:05 PM UTC

tom_mellior wrote: post #12

rwmj wrote: post #11

Tutorial and examples: http://scopes.readthedocs.io/en/latest/tutorial.html

The "unconst" business is... original, but it seems backwards to me. If I understand correctly, applying the Fibonacci function to a constant will compile a new version of the function, with the loop fully unrolled. And to avoid this, you have to mark some variable that is not the function argument but is initialized to a constant as "unconst". That just seems like a bizzarre source of confusion. I'm all for aggressi…

nota that Jai has a similar concept, can't give you a link right now. It allows a function to have several instantiations. The generic (slow) function is mostly documentation, not intended to be used :)

Re: The Scopes Programming Language

#23

Post by tom_mellior » Sat, Mar 17, 2018, 5:07 PM UTC

paniq303 wrote: post #21

tom_mellior wrote: post #16

Earlier quoted context omitted.

That code does indeed automatically delete some entries from some collection, and it does use garbage collection terminology, but it doesn't appear to be full garbage collection for the whole language. Hard to tell in the complete absence of comments and a commit message. But http://scopes.readthedocs.io/en/latest/about.html says "The memory model is compatible to C/C++ and utilizes simple unmanaged stack and heap me…

> That code does indeed automatically delete some entries from some collection, and it does use garbage collection terminology, but it doesn't appear to be full garbage collection for the whole language. Hard to tell in the complete absence of comments and a commit message. It's very old code from two years ago, when the language was still being prototyped. I did have a form of GC for a while that I threw away again…

> Also, why "fortunately"?

Because I think it's a lot harder (both for you and for your users) than you thought at the time, and I hoped you wouldn't waste your time (and your users' time) on it. Personally, I think GC is the way to go to keep your (programmers') sanity. If you worry about GC pauses in time-critical sections, provide for a way to turn off the GC temporarily for such sections.

You might want to mark such non-GC sections/functions specifically and enforce statically that no dynamic allocation may be triggered from within them. Kind of like a monad. No allocations, no GCs, no headaches. Simpler and more flexible than the Rust model.

> No insult was intended.

I didn't read that as such!

Re: The Scopes Programming Language

#24

Post by tom_mellior » Sat, Mar 17, 2018, 5:15 PM UTC

paniq303 wrote: post #17

tom_mellior wrote: post #12

Earlier quoted context omitted.

The "unconst" business is... original, but it seems backwards to me. If I understand correctly, applying the Fibonacci function to a constant will compile a new version of the function, with the loop fully unrolled. And to avoid this, you have to mark some variable that is not the function argument but is initialized to a constant as "unconst". That just seems like a bizzarre source of confusion. I'm all for aggressi…

Regarding "unconst", we need to have a discussion. There are ways to make it implicit, namely by tying the return continuation of `if` to the constness of the conditional, but then one loses the ability to specialize the return continuation for constant results. Named `let` is the most primitive form of loop, suitable for use in runtime and compile time (constexpr-style) context. There are more convenient, less versa…

> I don't think that programmers want big loops to unroll.

Right, well, it depends. That's why I think unconst should be the default and unrolling should be requested explicitly by using something like

    let fib_2000 = specialize (fib 2000)

where specialize is a language built-in that triggers the unrolling. And then, if the user really does want you to specialize fib 2147483647, it would honor that too, without your arbitrary unrolling cutoff. And if it takes too long, well, the user wanted it that way. That is user control. Arbitrary hidden cutoffs are not.

Re: The Scopes Programming Language

#25

Post by jaccarmac » Sat, Mar 17, 2018, 5:42 PM UTC

tom_mellior wrote: post #24

paniq303 wrote: post #17

Earlier quoted context omitted.

Regarding "unconst", we need to have a discussion. There are ways to make it implicit, namely by tying the return continuation of `if` to the constness of the conditional, but then one loses the ability to specialize the return continuation for constant results. Named `let` is the most primitive form of loop, suitable for use in runtime and compile time (constexpr-style) context. There are more convenient, less versa…

> I don't think that programmers want big loops to unroll. Right, well, it depends. That's why I think unconst should be the default and unrolling should be requested explicitly by using something like let fib_2000 = specialize (fib 2000) where specialize is a language built-in that triggers the unrolling. And then, if the user really does want you to specialize fib 2147483647, it would honor that too, without your a…

On the other hand, I like unconst on first sight. A symmetrical form to do specialization would be nice too. What about making the loop unrolling configurable, whether with a compiler flag or some form like Lisp's declare.

Re: The Scopes Programming Language

#26

Post by ken » Sat, Mar 17, 2018, 5:42 PM UTC

chenglou wrote: post #15

From the intro: http://scopes.readthedocs.io/en/latest/about.html > the compiler is designed to remain on-line at runtime so that functions can be recompiled when the need arises, and generated machine code can adapt to the instruction set present on the target machine. This also diminishes the need for a build system Diminishing the need for a build system is nice! Any other language with such philosophy in mind?

It hasn't obviated the need for a build system, but this is a traditional feature of Lisp [1]. With modern security requirements, though, I'm not sure how popular this approach is going to be.

[1]: http://www.paulgraham.com/diff.html "The whole language always available"

Re: The Scopes Programming Language

#27

Post by paniq303 » Sat, Mar 17, 2018, 5:50 PM UTC

tom_mellior wrote: post #24

paniq303 wrote: post #17

Earlier quoted context omitted.

Regarding "unconst", we need to have a discussion. There are ways to make it implicit, namely by tying the return continuation of `if` to the constness of the conditional, but then one loses the ability to specialize the return continuation for constant results. Named `let` is the most primitive form of loop, suitable for use in runtime and compile time (constexpr-style) context. There are more convenient, less versa…

> I don't think that programmers want big loops to unroll. Right, well, it depends. That's why I think unconst should be the default and unrolling should be requested explicitly by using something like let fib_2000 = specialize (fib 2000) where specialize is a language built-in that triggers the unrolling. And then, if the user really does want you to specialize fib 2147483647, it would honor that too, without your a…

unconst can't be the default because there is no way to re-const a value once it's been turned into an unknown. The most "automagic" behavior is to tie branch conditionals to their exit values (there's a helper function called tie-const that does this for the manual case). If the conditional is unknown at compile time, then the continuations that exit the branch will mark their arguments as unknown. That also stops loops from unrolling (they'd typically unroll for i=0, but then stop). But, as I mentioned before, that completely kills constant folding at the exit points, something that is at times desirable.

Another reason loops are unrolling by default is that there are many situations where constexprs have to completely fold at compile time, and you need a guarantee that they do. A common example is handling keyed varargs. You need to be able to iterate through the keys and build local variables from that without any code being generated.

If a compile time unroll takes forever, there's practically no clean way to debug that.

Re: The Scopes Programming Language

#28

Post by paniq303 » Sat, Mar 17, 2018, 6:04 PM UTC

tom_mellior wrote: post #23

paniq303 wrote: post #21

Earlier quoted context omitted.

> That code does indeed automatically delete some entries from some collection, and it does use garbage collection terminology, but it doesn't appear to be full garbage collection for the whole language. Hard to tell in the complete absence of comments and a commit message. It's very old code from two years ago, when the language was still being prototyped. I did have a form of GC for a while that I threw away again…

> Also, why "fortunately"? Because I think it's a lot harder (both for you and for your users) than you thought at the time, and I hoped you wouldn't waste your time (and your users' time) on it. Personally, I think GC is the way to go to keep your (programmers') sanity. If you worry about GC pauses in time-critical sections, provide for a way to turn off the GC temporarily for such sections. You might want to mark s…

> Because I think it's a lot harder (both for you and for your users) than you thought at the time, and I hoped you wouldn't waste your time (and your users' time) on it.

I believe it is possible to offer such a feature without declarative baggage. If it's not, then I don't want it ;-)

> Personally, I think GC is the way to go to keep your (programmers') sanity. If you worry about GC pauses in time-critical sections, provide for a way to turn off the GC temporarily for such sections.

It might be even possible to leverage Scopes' support for compile-time introspection to write contextual GC's from within the language. I haven't explored that yet. In games development we usually prefer to allocate in frames, stages or on custom stacks, so that's also a way to do it.

Installing a GC at the lowest level is a brutal choice that precludes many other possible ways this could go, so I'm cautious.

Re: The Scopes Programming Language

#29

Post by lispm » Sat, Mar 17, 2018, 8:02 PM UTC

chenglou wrote: post #15

From the intro: http://scopes.readthedocs.io/en/latest/about.html > the compiler is designed to remain on-line at runtime so that functions can be recompiled when the need arises, and generated machine code can adapt to the instruction set present on the target machine. This also diminishes the need for a build system Diminishing the need for a build system is nice! Any other language with such philosophy in mind?

> The Scopes compiler fundamentally differs from C++ and other traditional AOT (ahead of time) compilers, in that the compiler is designed to remain on-line at runtime so that functions can be recompiled when the need arises, and generated machine code can adapt to the instruction set present on the target machine. This also diminishes the need for a build system. Still, Scopes is not a JIT compiler. Compilation is always explicitly initiated by the user.

Many Lisp systems also have their native code compiler on-line.

Re: The Scopes Programming Language

#30

Post by toolslive » Sat, Mar 17, 2018, 8:18 PM UTC

paniq303 wrote: post #19

toolslive wrote: post #14

Is there support for effects or is there something like a concurrency monad ?

I don't know what those are, but Scopes is designed to make it easy for users to implement their own meta-programming abstractions. It might be possible to build such mechanisms from within the language. I certainly want to hear of the instances where it is not.

https://github.com/yallop/effects-bibliography

Anyway, the type of the print "hello world" expression would explain a lot.