Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
Is it because we want to conserve memory space?
Scott's answer is correct, but I want to pitch in with another perspective.
Scheme culture cares a great deal about functional programming. Functional code should not care about ordering of operations. This is, in fact, why an expression like (foo (bar) (baz (qux))) does not say anything about which order those functions will be run, except that:
qux will be run before baz is run
both bar and baz will be run before foo is run
In particular, qux can be run before or after bar, and even a sequence like qux → bar → baz → foo is valid.
For a similar reason, let should be used by default; it signals to the reader that the usual functional assumptions apply, that the bindings can be evaluated in any order. let* should only be used to alert the reader to the unusual behaviour of having bindings depend on previous ones in the same let* form.
let*, at the cost of being more capable, has to serialize the terms being defined (since each can depend on previous ones), whereas the terms in a let can be set up in any order (and even in parallel, should the architecture allow for that).
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 6 years ago.
Improve this question
7.2 Blocks in Ruby says..
"block is a piece of code that can't be stored in a variable and isn't an object. It is, as a consequence, significantly faster than a lambda, but not as versatile and also one of the rare instances where Ruby's 'everything is an object' rule is broken"
Going by Best explanation of Ruby blocks?, that doesn't seem right.
Are blocks (Proc) objects? And thus don't break the everything is object rule in Ruby?
No, blocks are not (Proc) objects (although it is easy to map from one to the other).
Obviously, "everything is object in Ruby" is wrong in the absolute sense. A character is not an object. Even if limit your attention to tokens, keywords are not objects; comments are not objects; parentheses are not objects. So it is not surprising that a block is not an object.
Every proposition has contexts in which it is to be interpreted. When people say "everything is object in Ruby", the context is "with respect to what some major languages regard as atomic/scalar, such as numerals, etc."
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
In Ruby, is there a preference for which level of parentheses to elide, or does it depend on the situation (in which case, what guidelines should be followed)? Sources are appreciated.
For example, is either
do_something do_something_else(...)
or
do_something(do_something_else ...)
better than the other?
You want a rule to decide when to omit parentheses and when not. And that should be based on the method. (It is cumbersome to base the rule depending on the context, i.e., always omit the innermost parentheses, or always omit the outermost parentheses., etc.)
And there are methods that are usually only used at the outermost level (i.e., do not become an argument of another method call), as opposed to no/few methods that only appear as the innermost level. Typical examples of the former are DSL methods (methods that are conventionally used without parentheses like puts, p can be considered parts of the DSL provided by Ruby itself).
Once you decide to base the rule on what the method is, it follows naturally that you would be omitting the outermost parentheses that appear with particular methods.
This is a primarily opinion-based question, but Ruby Style Guide is a good (best?) reference when style-related questions appear.
Assuming it should be consistent with rest of the assert in tests, and looking at way asserts are used in Rails tests (i.e. with no parenthesis), it will be apt to use
assert method(param1, param2, etc)
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
while browsing for a contains method, I came across the following Q&A
contains-method-for-a-slice
It is said time and again in this Q&A that the method is really trivial to implement. What I don't understand is, if it were so easy to implement, and seeing how DRY is a popular software principle && and most modern languages implement said method , what sort of design reasoning could be involved behind the exclusion of such a simple method?
The triviality of the implementation depends on the scope of the implementation. It is trivial to implement when you know how to compare each value. Application code usually knows how to compare the types used in that application. But it is not trivial to implement in the general case for arbitrary types, and that is the situation for the language and standard library.
Figuring out if a slice contains a certain object is an O(n) operation where n is the length of the slice. This would not change if the language provided a function to do this. If your code relies on frequently checking if a slice contains a certain value, you should reevaluate your choice of data structures; a map is usually better in these kind of cases. Why should the standard library include functions that encourage you to use the wrong data structure for the task you have?
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
So I was just in racket and was thinking about using keys to interact with the computer and keys are interpreted as strings by racket. I am looking for optimization of my code and was wondering whether strings or symbols are faster to operate on.
If the set of possible keys is well-defined, use symbols. Otherwise, use strings.
The main difference between strings and symbols is that symbols are (by default) interned. With strings, you can have multiple strings that have the same contents, but are different objects (they do not compare as eq?). With symbols, two symbols that have the same contents are guaranteed to be the same object.
The advantage of this is that you can do symbol comparisons using eq?, whereas for strings you have to use string=? or equal?.
However, in order for this magic to happen, behind the scenes, Scheme implementations maintain an intern pool, which is basically like a string-to-symbol hash table. If you call string->symbol and the string is not already in the intern table, it will add the string (and its corresponding symbol) to the table, so if your set of possible keys is not well-defined, you can junk up the intern table pretty quickly.
Edit: When you say "keys", did you mean keyboard characters? That is definitely a well-defined set, so you can use symbols.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
In languages that use 'curly braces' for code blocks, and where whitespace isn't a concern (C, Java, PHP) - What are the names for the different bracing/indenting styles?
I remember reading about 'KNF' and 'Flag', but it'd be great to have the most recognized names, along with some simple examples of each.
Please see Indent style:
In computer programming, an indent
style is a convention governing the
indentation of blocks of code to
convey the program's structure. This
article largely addresses the C
programming language and its
descendants, but can be (and
frequently is) applied to most other
programming languages (especially
those in the curly bracket family).
Indent style is just one aspect of
programming style.