Am Sun, 12 Aug 2012 00:17:44 +0200
schrieb Timon Gehr <timon.gehr@gmx.ch>:

> On 08/11/2012 01:24 PM, Marco Leise wrote:
> > Am Fri, 10 Aug 2012 15:56:53 +0200
> > schrieb Timon Gehr<timon.gehr@gmx.ch>:
> >
> >> int eval(scope Expr* e){
> >>       final switch(e.tag) with(Expr.Tag){
> >>           case val:   return e.i;
> >>           case plus:  return eval(e.a) + eval(e.b);
> >>           case minus: return eval(e.a) - eval(e.b);
> >>       }
> >> }
> >
> > Can you quickly explain the use of scope here?
> > Does that mean "I wont keep a reference to e"?
> 
> It means "I won't keep a reference to *e", but I assume that is what was meant.
> 
> > What are the implications?
> 
> The caller has some confidence that passing a pointer to stack- allocated data is safe.
> 
> > Does scope change the method signature?
> 
> Yes. It is eg. impossible to override a method that has a scope parameter with a method that does not have a scope parameter.
> 
> > Does the compiler enforce something?
> 
> In this case and currently, it is merely documentation.
> I think it should be enforced and cast(scope) should be added
> to allow non-@safe code to escape the conservative analysis.
> 
> > Will generated code differ?
> 
> Only the mangled symbol name will differ. (unlike when scope is used on delegate parameters, in this case it prevents closure allocation at the call site.)
> 
> > Does it prevent bugs or is it documentation for the user of the function?
> 
> It is just documentation, both for the user and the maintainer.
> 
> > Thanks in advance for some insight!
> >

Now that looks like a good 'scope' FAQ. thx

-- 
Marco

Am 11.08.2012 20:37, schrieb Peter Alexander:
> On Saturday, 11 August 2012 at 18:04:29 UTC, Paulo Pinto wrote:
>> On Saturday, 11 August 2012 at 16:12:14 UTC, Peter Alexander wrote:
>>> On Saturday, 11 August 2012 at 14:45:55 UTC, Russel Winder wrote:
>>>> On Sat, 2012-08-11 at 02:19 +0200, David Piepgrass wrote:
>>>> […]
>>>>> I hope someday to have a programming system whose features are not
>>>>> limited to whatever features the language designers saw fit to
>>>>> include -- a language where the users can add their own features,
>>>>> all the while maintaining "native efficiency" like D. That language
>>>>> would potentially allow Rust-like code, D-like code, Ruby-like code
>>>>> and even ugly C-like code.
>>>>>
>>>>> I guess you don't want to be the one to kickstart that PL. I've
>>>>> been planning to do it myself, but so far the task seems just too
>>>>> big for one person.
>>>>
>>>> <quasi-troll>
>>>> Isn't that language Lisp?
>>>> </quasi-troll>
>>>
>>> You missed the native efficiency part :-)
>>>
>> You mean like the Common Lisp compilers that are able to beat FORTRAN
>> compilers
>> in floating point computations?
>>
>> http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.54.5725
>>
>> --
>> Paulo
>
> Not sure where you read that in the paper.
>
>  From the conclusion:
>
> "We have demonstrated that the speed of compiled Common Lisp code,
> though today somewhat slower than that of the best compiled Fortran,
> could probably be as efficient, and in some ways superior."
>
> Probably is the operative word there.

Should have re-read the paper. It has been a few years since I fully read it. Still I think Common Lisp code is pretty efficient.

>
>> Most modern Lisp implementations employ JITing one way or another, so
>> you do get native code. Just not on the first run through a bit of code.
>
> JIT has its limits. A dynamically typed language is still dynamically
> typed once compiled. Sure the JIT may be able to deduce the types in
> some cases, but not all.
>
> I do see your point, but in general it's still not as fast as optimised C.

I imagine you wanted to answer to Russel's post.

On Lisp's case, most systems available today only JIT when using the REPL, as you can always compile to native code.

Type annotations help improve the speed in hotspot areas of your code,
in case you really need the extra speed for the application use case.

As for the speed of native code produced by JITs for dynamic languages,
I think Cog(Smalltalk), Self(Smaltalk ended up becoming JVM Hotspot),
PyPy (Python), V8(JavaScript), LLVM(Julia) prove that you can get pretty close to C for the majority of use cases that matter to the common user.

Actually a running assumption among the dynamic languages advocates is that
if dynamic languages had had as much money and research support as the
static languages field, the compilers would be much better by now.

--
Paulo

Am Sun, 12 Aug 2012 00:17:44 +0200
schrieb Timon Gehr <timon.gehr@gmx.ch>:

> On 08/11/2012 01:24 PM, Marco Leise wrote:
> > Am Fri, 10 Aug 2012 15:56:53 +0200
> > schrieb Timon Gehr<timon.gehr@gmx.ch>:
> >
> >> int eval(scope Expr* e){
> >>       final switch(e.tag) with(Expr.Tag){
> >>           case val:   return e.i;
> >>           case plus:  return eval(e.a) + eval(e.b);
> >>           case minus: return eval(e.a) - eval(e.b);
> >>       }
> >> }
> >
> > Can you quickly explain the use of scope here?
> > Does that mean "I wont keep a reference to e"?
> 
> It means "I won't keep a reference to *e", but I assume that is what was meant.
> 
> > What are the implications?
> 
> The caller has some confidence that passing a pointer to stack- allocated data is safe.
> 
> > Does scope change the method signature?
> 
> Yes. It is eg. impossible to override a method that has a scope parameter with a method that does not have a scope parameter.
> 
> > Does the compiler enforce something?
> 
> In this case and currently, it is merely documentation.
> I think it should be enforced and cast(scope) should be added
> to allow non-@safe code to escape the conservative analysis.

There are probably some more, less known use cases. For example this
recent thread on stackoverflow shows how scope might be necessary to
initialize an immutable variable.
http://stackoverflow.com/questions/11860584/changing-immutable-members-inside-the-constructor

Paulo Pinto:

> As for the speed of native code produced by JITs for dynamic languages,
> I think Cog(Smalltalk), Self(Smaltalk ended up becoming JVM Hotspot),
> PyPy (Python), V8(JavaScript), LLVM(Julia) prove that you can get pretty close to C for the majority of use cases that matter to the common user.

Among V8 developers thee are some ex Self developers.
I think at the moment there aren't enough Julia benchmarks to allow us to judge its performance well enough.
PyPy is surely not close to C speeds when it JITs Python code (PyPy developers need to stop using just their few benchmarks and try to optimize many other programs).
And you miss the best of the bunch, the Lua JIT.

One problem with JITs is that they give you a good performance if they are well implemented and if the the GC is good. While older languages produce decent performance even with a simple compiler.

Bye,
bearophile

On Sunday, 12 August 2012 at 11:28:28 UTC, bearophile wrote:
> Paulo Pinto:
>
>> As for the speed of native code produced by JITs for dynamic languages,
>> I think Cog(Smalltalk), Self(Smaltalk ended up becoming JVM Hotspot),
>> PyPy (Python), V8(JavaScript), LLVM(Julia) prove that you can get pretty close to C for the majority of use cases that matter to the common user.
>
> Among V8 developers thee are some ex Self developers.
> I think at the moment there aren't enough Julia benchmarks to allow us to judge its performance well enough.
> PyPy is surely not close to C speeds when it JITs Python code (PyPy developers need to stop using just their few benchmarks and try to optimize many other programs).
> And you miss the best of the bunch, the Lua JIT.

Yeah, silly me forgeting about LuaJIT.

>
> One problem with JITs is that they give you a good performance if they are well implemented and if the the GC is good. While older languages produce decent performance even with a simple compiler.
>
> Bye,
> bearophile


True, this year's Google IO V8 talk has lots of informations on how
you write JavaScript code can influence the code quality generated by V8.

From the compiler design geek I used to be, I find very interesting to
get myself informed about this area, and I think that dynamic languages JITs still have a lot of room to improve.

Although personally I prefer static languages with native compilers for my
own coding projects.

--
Paulo

On 08/12/2012 10:17 AM, Johannes Pfau wrote:
>
> There are probably some more, less known use cases. For example this
> recent thread on stackoverflow shows how scope might be necessary to
> initialize an immutable variable.
> http://stackoverflow.com/questions/11860584/changing-immutable-members-inside-the-constructor
>
>

Such rules are not part of the current language. The comment that says
that they are is wrong. scope does not currently influence type
checking at method call boundaries.