language-design

How to efficiently implement closures in LLVM IR?

我只是一个虾纸丫 提交于 2019-12-04 08:18:04
问题 I started adding closures (lambdas) to my language that uses LLVM as the backend. I have implemented them for simple cases where they can be always inlined i.e. code for the closure definition itself doesn't need to be generated, as it is inlined where used. But how to generate the code for a closure in case the closure isn't always inlined (for example, it is passed to another function that isn't inlined). Preferably, the call sites shouldn't care whether they are passed regular functions or

Closures in Scala vs Closures in Java

ⅰ亾dé卋堺 提交于 2019-12-04 08:15:23
问题 Some time ago Oracle decided that adding Closures to Java 8 would be an good idea. I wonder how design problems are solved there in comparison to Scala, which had closures since day one. Citing the Open Issues from javac.info: Can Method Handles be used for Function Types? It isn't obvious how to make that work. One problem is that Method Handles reify type parameters, but in a way that interferes with function subtyping. Can we get rid of the explicit declaration of "throws" type parameters?

How come Go doesn't have stackoverflows

笑着哭i 提交于 2019-12-04 07:58:35
问题 I read in this presentation http://golang.org/doc/ExpressivenessOfGo.pdf page 42: Safe - no stack overflows How is this possible? and/or how does Go works to avoid this? 回答1: It's a feature called "segmented stacks": every goroutine has its own stack, allocated on the heap. In the simplest case, programming language implementations use a single stack per process/address space, commonly managed with special processor instructions called push and pop (or something like that) and implemented as

Is Lua based primarily on well-established programming-language ideas? [closed]

北慕城南 提交于 2019-12-04 07:26:18
问题 As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. Closed 7 years ago . Lua occupies a good place in the space of languages that can be embedded. Are the primary ideas behind Lua's design new ideas from the

Why can I access private/protected methods using Object#send in Ruby?

泄露秘密 提交于 2019-12-04 07:19:46
The class class A private def foo puts :foo end public def bar puts :bar end private def zim puts :zim end protected def dib puts :dib end end instance of A a = A.new test a.foo rescue puts :fail a.bar rescue puts :fail a.zim rescue puts :fail a.dib rescue puts :fail a.gaz rescue puts :fail test output fail bar fail fail fail .send test [:foo, :bar, :zim, :dib, :gaz].each { |m| a.send(m) rescue puts :fail } .send output foo bar zim dib fail The question The section labeled "Test Output" is the expected result. So why can I access private/protected method by simply Object#send ? Perhaps more

Why does CMake syntax have redundant parentheses everywhere?

╄→尐↘猪︶ㄣ 提交于 2019-12-04 04:51:36
CMake's if s go like this: if (condition) ... else if (...) ... else (...) ... endif (...) With else if (...) the (...) tests for a separate condition. Why else (...) and not just else ? Why endif (...) and not endif ? Cmake's functions go like this: function(funcname ...) ... endfunction(funcname ...) Why endfunction(funcname ...) and not simply endfunction ? I can omit the contents of the redundant parenthesis where they appear, like so: endif () . What's the purpose of this construct? Antonio I believe the initial intention was that, by repeating at each clause (for example, else statement)

Short circuit evaluation using procedures

醉酒当歌 提交于 2019-12-04 03:57:35
问题 I am currently developing a compiler for a very limited object oriented language. I want to treat all values as objects and operators on those values will be implemented as methods. The compiler transforms the program into assembler for a stack-based virtual machine. During compilation I transform integer literals into objects of a special "Integer" class. Arithmetic operators are implemented as methods of that class (using inline assembler). So that 4 + 5 basically equals to 4.add(5) . The

Why can't I use an array index on the return value of a function? [closed]

笑着哭i 提交于 2019-12-04 03:36:33
问题 It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center. Closed 8 years ago . Why can't I do this? explode(',','1,2,3', 1)[0] Every other language supports it. Answers I'm looking for: (since people seem to think this is a pointless rant) Is there some sort of a difference between how a

Why does java have no byte type suffix? [closed]

血红的双手。 提交于 2019-12-04 02:22:42
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. Closed 9 years ago . So java has a long type suffix for literals: (123L), a double type suffix (43.21D), a floating point suffix (1.234F). So ... why no byte type suffix? For example, when writing some testing code you MUST cast all your bytes when they are

On async return type

杀马特。学长 韩版系。学妹 提交于 2019-12-04 02:11:10
问题 Wondering why we should specify that async method does return Task object. Specifying it seems redundant with the async keyword plus it is confusion since you do not really create the Task object. As I understand the compiler does emit the necessary code for Task object creation (Whether on a await call or wrapping the return with a new Task.). I don't really like the inconsistency between the declare type and the return Type. 回答1: I have a blog post that describes the reasoning in detail.