Is it possible to invert the behavior of break hints in the Format module, e.g. using standard spaces as break hints, and adding some special notation for non-breakable spaces?
The current behavior leads to situations where one might be inclined to write "Hello# world,# this# is# a# short# phrase", where every space is converted into a break hint to mimic the behavior as seen e.g. in text editors, HTML renderers, etc.
For instance, this Using the Format module documentation explicitly recommends using break hints:
Generally speaking, a printing routine using "format", should not directly output white spaces: the routine should use break hints instead.
This behavior not only complicates writing messages, but it also makes it very hard to grep strings in the source code.
It seems that following the established convention that "every space is a break hint, unless marked as non-breaking space" would be a better alternative.
Are there simple techniques to wrap such strings and invert their behavior, preferably that incur no excessive runtime cost and/or lead to typing issues (e.g. due to conversions between string and format)?
Since 4.02 there is a Format.pp_print_text function that will take a regular text and print it substituting spaces with cuts and \n with new_lines.
Using this function you can still print using printf and other convenience functions:
printf "text '%a'" pp_print_text "hello, this a short phrase"
In general your question is more about library design. So, it is hard to answer anything about it. It is more suited for discussion on the OCaml mailing list.
Related
Whenever I see a Julia macro in use like #assert or #time I'm always wondering about the need to distinguish a macro syntactically with the # prefix. What should I be thinking of when using # for a macro? For me it adds noise and distraction to an otherwise very nice language (syntactically speaking).
I mean, for me '#' has a meaning of reference, i.e. a location like a domain or address. In the location sense # does not have a meaning for macros other than that it is a different compilation step.
The # should be seen as a warning sign which indicates that the normal rules of the language might not apply. E.g., a function call
f(x)
will never modify the value of the variable x in the calling context, but a macro invocation
#mymacro x
(or #mymacro f(x) for that matter) very well might.
Another reason is that macros in Julia are not based on textual substitution as in C, but substitution in the abstract syntax tree (which is much more powerful and avoids the unexpected consequences that textual substitution macros are notorious for).
Macros have special syntax in Julia, and since they are expanded after parse time, the parser also needs an unambiguous way to recognise them
(without knowing which macros have been defined in the current scope).
ASCII characters are a precious resource in the design of most programming languages, Julia very much included. I would guess that the choice of # mostly comes down to the fact that it was not needed for something more important, and that it stands out pretty well.
Symbols always need to be interpreted within the context they are used. Having multiple meanings for symbols, across contexts, is not new and will probably never go away. For example, no one should expect #include in a C program to go viral on Twitter.
Julia's Documentation entry Hold up: why macros? explains pretty well some of the things you might keep in mind while writing and/or using macros.
Here are a few snippets:
Macros are necessary because they execute when code is parsed,
therefore, macros allow the programmer to generate and include
fragments of customized code before the full program is run.
...
It is important to emphasize that macros receive their arguments as
expressions, literals, or symbols.
So, if a macro is called with an expression, it gets the whole expression, not just the result.
...
In place of the written syntax, the macro call is expanded at parse
time to its returned result.
It actually fits quite nicely with the semantics of the # symbol on its own.
If we look up the Wikipedia entry for 'At symbol' we find that it is often used as a replacement for the preposition 'at' (yes it even reads 'at'). And the preposition 'at' is used to express a spatial or temporal relation.
Because of that we can use the #-symbol as an abbreviation for the preposition at to refer to a spatial relation, i.e. a location like #tony's bar, #france, etc., to some memory location #0x50FA2C (e.g. for pointers/addresses), to the receiver of a message (#user0851 which twitter and other forums use, etc.) but as well for a temporal relation, i.e. #05:00 am, #midnight, #compile_time or #parse_time.
And since macros are processed at parse time (here you have it) and this is totally distinct from the other code that is evaluated at run time (yes there are many different phases in between but that's not the point here).
In addition to explicitly direct the attention to the programmer that the following code fragment is processed at parse time! as oppossed to run time, we use #.
For me this explanation fits nicely in the language.
thanks#all ;)
Background:
I am implementing a language similar to Ruby, called Sapphire, as a way to try out some Ideas I have on concurrency in programming languages. I am trying to copy Ruby's double quoted strings with embedded code which I find very useful as a programmer.
Question:
How do any of the Ruby interpreters turn a double quotes string with embedded code into and AST?
eg:
puts "The value of foo is #{#foo}."
puts "this is an example of unmatched braces in code: #{ foo.go('}') }"
Details:
The problem I have is how to decide which } closes the code block. Code blocks can have other braces within them and with a little effort they can be unmatched. The lexer can find the beginning of a code block in a string, but without the aid of the parser, it cannot know for sure which character is the end of that block.
It looks like Ruby's parse.y file does both the lexing and parsing steps, but reading that thing is a nightmare it is 11628 lines long with no comments and lots of abbr.
True, Yacc files can be a bit daunting to read at first and parse.y is not the best file to start with. Have you looked at the various string production rules? Do you have any specific questions?
As for the actual parsing, it's indeed not uncommon that lexers do also parse numeric literals and strings, see e.g. the accepted answer to a similar question here on SO. If you approach things this way, it's not too hard to see how to go about it. Hitting #{ inside a string, basically starts a new parsing context that gets parsed as an expression again. This means that the first } in your example can't be the terminating one for the interpolation, since it's part of a literal string within the expression. Once you reach the end of the expression (keep in mind expression separators like ;), the next } is the one you need.
This is not a complete answer, but I leave it in hopes that it might be useful either to me or one who follows me.
Matz gives a pretty detailed rundown of the yylex() function of parse.y in chapter 11 of his book. It does not directly mention strings, but it does describe how the lexer uses lex_state to resolve several locally ambiguous constructs in Ruby.
A reproduction of an English translation of this chapter can be found here.
Please bear in mind that they don't have to (create an AST at compile time).
Ruby strings can be assembled at runtime and will interpolate correctly. Therefore all the parsing and evaluation machinery has to be available at runtime. Any work done at compile time in that sense could be considered an optimisation.
So why does this matter? Because there are very effective stack-based techniques for parsing and evaluating expressions that do not create or decorate an AST. The string is read (parsed) from left to right, and as embedded tokens are encountered they are either evaluated or pushed on a stack, or cause stack contents to be popped and evaluated.
This is a simple technique to implement provided the expressions are relatively simple. If you really want the full power of the language inside every string, then you need the full compiler at runtime. Not everyone does.
Disclosure: I wrote a commercial language product that does exactly this.
Dart also supports expressions interpolated into strings like Ruby, and I've skimmed a few parsers for it. I believe what they do is define separate tokens for a string literal preceding interpolation and a string literal at the end. So if you tokenize:
"before ${the + expression} after"
You would get tokens like:
STRING_START "before "
IDENTIFIER the
PLUS
IDENTIFIER expression
STRING " after"
Then in your parser, it's a pretty straightforward process of handling STRING_START to parse the interpolated expression(s) following it.
Our Ruby parser (see my bio) treats Ruby "strings" as complex objects having lots of substructures, including string start and end tokens, bare string literal fragments, lots of funny punctuation sequences representing the various regexp operators, and of course, recursively, most of Ruby itself for expressions nested inside such strings.
This is accomplished by allowing the lexer to detect and generate such string fragments in a (for Ruby, many) special lexing modes. The parser has a (sub)grammar that defines valid sequences of tokens. And that kind of parsing solves OP's original problem; the parser knows whether a curly brace matches other curly braces from the regexp content, and/or if the regexp has been completely assembled and the curly brace is a matching block end.
Yes, it builds an AST of the Ruby code, and of the regexps.
The purpose of all this is to allow us to build analyzers and transformers of Ruby code. See https://softwarerecs.stackexchange.com/q/11779/101
The D Programming Language has at least two attributes prefixed with the "#" symbol:
#disable
#property
What sort of meaning is "#" supposed to convey? I can't seem to locate anything relevant in the documentation.
Also, why is __gshared the only attribute with two leading underscores?
It has no meaning.
Yes, that probably wasn't what you were hoping to hear -- but that's what they've said in the newsgroups.
The # doesn't really mean anything at this point. All of the #x words are function attributes. The # was tacked on pretty much just to save keywords. So, in general, newer attributes have # on them and older ones don't (though there was some shuffling around of that a while back where there was some debate over whether some of the attributes should have # or not). If they were redone from scratch without caring what other languages have done, then you might have gotten # on all of the function attributes, but there was no way that stuff like #public was going to happen, since it would have just made porting code harder for no real benefit. The end result is that what got # and what didn't is fairly arbitrary. You just have to remember which attributes start with # and which don't, but that's not all that much different from having to learn new keywords. It's just that these are prefixed with # so that they aren't actually keywords and don't reduce the number of legal identifiers in the language.
Now, there's definitely a desire among many in the D community to use # for custom attributes in the future, in which case, # would indicate a custom attribute in the cases where the name used wasn't one built into the language, but for all of the ones built into the language, it pretty much just amounts to saving a keyword.
As Mehrdad shows (see the links in the comments), there's no special meaning to "#", they are how they are just for historical reasons.
As for your other question, __gshared isn't the only keyword with two underscores, there's also __thread and __traits. This naming convention is commonly used to denote internal data structures, which need to be exposed for practical reasons but are not "safe" to use in all cases (i.e. more a hack than a well-established feature). I'm not sure whether or not the D language follows this convention, but seeing this quote from the docs I believe that's the case:
__gshared is disallowed in safe mode.
I'm searching for more info about __thread and __traits (which indeed are not attributes), but so far could find very little.
Often enough, I find myself dealing with lists of function options (or more general replacement lists) of the form {foo->value,...}. This leads to bugs when foo already has a value in $Context. One obvious way to prevent this is using a string "foo" instead of the symbol: {"foo"->value,...}. This works, but seems to draw ire of some seasoned LISPers I know, who chastise me for conflating symbols and strings and tell me to use built-in quoting constructs.
While it is certainly possible to write code that avoids collisions without using strings, it often seems more trouble than it is worth. On the other hand, I haven't seen too many examples of {"string"->value} type replacement rules. So the question to you is -- is this an acceptable usage pattern?.. Are there cases where it is particularly appropriate?.. Where should it be avoided?..
In my opinion (disclaimer - it is only my opinion), it is best to avoid using strings as option names, at least for "main" options in your function. Strings OTOH are totally fine as settings (r.h.s. of options). This is not to say that you can not use strings, just as you noted. Perhaps, they could be more appropriate for sub-options, and they are used in this way by many system functions (usually "superfunctions" like NDSolve, that may have sub-options within options). The main problems I see with using strings is that they reduce the introspection capabilities, both for the system and for the user. In other words, it is harder to discover an option that has a string name than that with a symbol name - for the latter I can just inspect the names of the symbols in a package, and also symbolic option names have usage messages. You may also want to automate some things, such as writing a utility that finds all option names in the package etc. It is easier to do when option names are symbols, since they all belong to the same context. It is also easy to discover that some options do not have usage messages, one can do that automatically by writing a utility function.
Finally, you may have a better protection against accidental collisions of similar option names. It may be, that many option sequences are passed to your function, and occasionally they may contain options with the same name. If option names were symbols, full symbol names would be different. Then, you will both get a shadowing warning, and at the same time a protection - only the correct option (full) name will be used. For string, you don't get any warning, and may end up using incorrect option setting, if the duplicate string option name with a wrong setting (intended for a different function, say) happens to be first in the list. This scenario is more likely to occur in larger projects, but bugs like this are probably very hard to catch (this is a guess, I never had such situation).
As for possible collisions, if you follow some naming conventions such as option name always starting with a capital letter, plus put most of your code in packages, and do not start your variable or function names (for functions in the interactive session), with a capital letter, then you will greatly reduce the chance of such collisions. Additionally, you should Protect option names, when you define them, or at the end of the package. Then, the collisions will be detected as cases of shadowing. Avoiding shadowing, OTOH, is a general necessity, so the case of options is no more special in this respect than for function names etc.
I'm learning Ruby in my spare time, and I have a question about language constructs for constants. Does Ruby have an equivalent of the C++ const keyword to keep variables from being modified? Here's some example code:
first_line = f.gets().chomp()
column_count = first_line.split( %r{\s+} ).size()
print column_count, "\n"
I'd like to declare column_count to be const, because I use it below in my program and I really don't want to modify it by mistake. Does Ruby provide a language construct for doing this, or should I just suck it up and realize that my variables are always mutable?
Response to comments:
'The most likely cause of "accidental" overwriting of variables is, I'd guess, long blocks of code.' I agree with the spirit of your point, but disagree with the letter. Your point about avoiding long blocks of code and unnecessary state is a good one, but for constants can also be useful in describing the design of code inside of the implementation. A large part of the value of const in my code comes from annotating which variables I SHOULD change and which I shouldn't, so that I'm not tempted to change them if I come back to my code next year. This is the same sentiment that suggests that code that uses short comments because of good variable names and clear indentation is better than awkwardly written code explained by detailed comments.
Another option appears to be Ruby's #freeze method, which I like the look of as well. Thanks for the responses everyone.
Ruby variables in general are, well, variable.
Beyond Jeremy's answer, while entirely accurate, doesn't lead you to a Ruby style that's very "mainstream" or idiomatically sound and I wouldn't recommend it for adoption. Ruby doesn't work like C++ and generally isn't very appropriate for things that C++ is best used for. Operating systems, word processors, that kind of thing.
The most likely cause of "accidental" overwriting of variables is, I'd guess, long blocks of code. After all, if you change the value of a variable in a five-line method, it's going to be fairly apparent! If you're habitually writing blocks of code longer than, say, 10 lines, then those chunks are probably doing too many things and I strongly advise that you make efforts to break them up (increase cohesion). Localise variables as much as possible to minimise the chance of unexpected side-effects (reduce coupling).
By convention, constants in ruby are generally written in all caps such as COLUMN_COUNT. But as it was pointed out, all variables that start with a capital letter are Constants.
Variables that start with a capital letter are constants in Ruby. So you could change your code to this:
first_line = f.gets().chomp()
Column_count = first_line.split( %r{\s+} ).size()
print Column_count, "\n"
Now you'll get a warning if you try to modify Column_count.