I'd like to modify the lua 5.2 source code to allow for an optional "global" keyword to precede global variable declarations. Has any done this or does anyone know how to do this (safely)? And yes I am aware that variables are global by default and that this would be purely syntactic sugar.
To be clear, adding custom keywords of existing types is straight forward. The part I'm at a loss for is how to safely edit the parser (via the 5.2 C source code) so that it discards or ignores the new "global" keyword.
Figured it out. First I appended a new token TK_GLOBAL to the end of the RESERVED enum.
Then in luaX_init() I added...
ts = luaS_new(L, "global");
luaS_fix(ts);
ts->tsv.reserved = cast_byte(TK_GLOBAL+1-FIRST_RESERVED);
And finally in the statement() function I added...
case TK_GLOBAL:
luaX_next(ls);
break;
As far as I can tell it works. Hopefully it's safe.
See this discussion for details and a proposed patch (against 5.3): http://lua-users.org/lists/lua-l/2018-07/msg00422.html. It uses a different (non-keyword based) approach, but should be a good starting point.
Related
Trying to implement something like this:
arr = (1..10)
arr[2,5] = [2,3,4,5]
arr(2,5] = [3,4,5]
arr[2,5) = [2,3,4]
arr(2,5) = [3,4]
Well, we need to override four bracket opreators: [], [), (], ()
Any ideas?
It's called "Including or excluding" in mathematics. https://en.wikipedia.org/wiki/Interval_(mathematics)#Including_or_excluding_endpoints
In short, this is not possible with the current Ruby parser.
The slightly longer answer: You'd have to start by modifying parse.y to support the syntax you propose and recompile Ruby. This is of course not a terrible practical approach, since you'd have to do that again for every new Ruby version. The saner approach would be to start a discussion on ruby-core to see if there is sufficient interest for this to be made part of the language (probably not tbh).
Your wanted syntax is not valid for the Ruby parser, but it could be implemented in Ruby with the help of self-modifying code.
The source files need to be pre-processed. A simple regular expression can substitute your interval expressions with ordinary method syntax, i.e.
arr[2,5] -> interval_closed(arr,2,5)
arr(2,5] -> interval_left_open(arr,2,5)
arr[2,5) -> interval_right_open(arr,2,5)
arr(2,5) -> interval_open(arr,2,5)
The string holding the modified source can be evaluated and becomes part of the application just like a source file on the hard disk. (See instance_eval)
The usage of self-modifying code should be well justified.
Is the added value worth the effort and the complications?
Does the code have to be readable for other programmers?
Is the preprocessing practical? E.g. will this syntax occur in one or a few isolated files, or be spread everywhere?
This question concerns phloc-schematron, a library for ISO Schematron validation.
I am creating schematron-files on the fly, so I have them available as document (or as string of course)
I cannot find a constructor for SchematronResourcePure that takes a string or document as argument, nor can I find a method to create a IReadableResource from the same.
Can someone suggest how to do this?
In case this is still relevant:
Switch to ph-schematron at https://github.com/phax/ph-schematron/ and use the static SchematronResourcePure.fromString method.
But you are right - this is a case that is currently not considered - building the Schematron from scratch. I will see, what I can do!
I have just stumbled across picoc and I am very impressed with what it can do - especially the fact that it can be extended by adding new functions etc. It saves me from going down the route of trying to "roll my own" interpreter.
However, I am wondering if there is anyway I can extend picoc by:
Adding new data types (for example, MySimpleDataType, MyPointerDataType)
Adding simple arithmetic operator functions (+,-,/, * etc) for my new data types.
Does anyone have any experience of doing this, or can someone provide pointers on how to go about adding new data types and their operator functions to picoc?
[[Edit]]
On further inspection of the code, I believe I have found how to add new data types (by modifying type.c). However, it is still not clear to me how to add arithmetic operators for new data types in picoc. Any help appreciated,
In general, C does not have operators overloading (while C++ does). Picoc is positioned as very tiny and having only the essentials, so I don't think it provides any extensions for it.
Adding new types can be done in the same manner that you can add new functions. A simple example of this can be had by examining picoc's source stdbool.c, where you'll find a typedef int bool; in the StdboolDefs element. You have to look elsewhere, include.c, to find the element in use; you'll find it as the "SetupCSource" parameter to an IncludeRegister() call.
Regarding adding new operators -- of course it's possible but only with a rather invasive change to the picoc library. As #yeputons said, the C language doesn't allow you to change or add operators, so there's no reason for picoc to directly support that.
I'm not sure I got how to define private functions right.
When I'm writing a package mathematica, I just do this:
BeginPackage["myPackage`"]
myPublicFunction::usage="myPublicFunction blahblahblah";
Begin["Private"]
myPrivateFunction[input_]:= ... ;
myPublicFunction[input_]:= ... ;
End[]
EndPackage[]
Is this the correct way or am I missing something?
Yep, that's a correct way. It may pay off to understand some of the internal package mechanics. Mathematica contexts are similar to namespaces in other languages. They can be nested. Every symbol belongs to some context. At any given moment, some context is "current". Whenever a new symbol is created, the system must decide to which context the symbol will belong. This happens at parse-time. The fundamental quantity (variable) here is $ContextPath. It is basically the search path for symbols. It is a list of contexts, and whenever the system sees a new symbol, it tests if the symbol with the same short name (that is, the name of the symbol proper, without the context) exists in some context on the $ContextPath. If it does exist, then the given occurrence of the symbol will be associated with that existing one. If it does not, then the symbol is created in a current context. Note that this is a dynamic thing - if you change the $ContextPath at any moment, the next symbol occurrence can be associated with a different symbol.
Anyways, what BeginPackage does is that it simply replaces the current value of $ContextPath with just {youPublicPackageContext, "System'"}, plus possibly additional contexts that you publicly import through the second optional argument of BeginPackage. Therefore, all symbols that are in the "public" section, are parsed into the public context, if they are not in "System'" or other contexts that you import. And what EndPackage does is to restore the value of the $ContextPath to what it was before you started loading the package. So, technically the usage message is not the only way to make a symbol public in your main context - you could just as well simply type a symbol with a semicolon, like myFunction; (this practice is discouraged, I just mentioned it to clarify the mechanism). Now, what happens when you enter Begin["'Private'"] is that the current context becomes YourContext'Private' (a sub-context). The $ContextPath is not changed. Therefore, any symbol entered there, which does not exist in your public package or other imported packages (that is, contexts currently on the $ContextPath), automatically is parsed into the 'Private' subcontext.
What really makes these symbols private is that whenever you import your package into some other context (package), only the main package is added to the $ContextPath, but not its sub-packages. Technically, you can break encapsulation by manually adding YourPackage'Private' to the $ContextPath (say, PrependTo[$ContextPath, YourPackage'Private']), and then all your private functions and other symbols will become public in that particular context where you do the import. Again, this practice is discouraged, but it explains the mechanics. The bottom line is that the notion of private or public can be entirely understood when we know how symbols are parsed, and what are the manipulations with $ContextPath and $Context (another system variable giving the value of the current context), that are performed by commands such as Begin and BeginPackage. To put it another way, one could, in principle, emulate the actions of BeginPackage,Begin, End and EndPackage with a user-defined code. There are just a few principles operating here (which I tried to outline above), and the mechanism itself is in fact very much exposed to the user, so that if, in some rare cases, one may want some other behavior, one can make some "custom" manipulations with $ContextPath and Context, to ensure some non-standard way of symbol parsing and therefore, control package-scale encapsulation in some "non-standard" way. I am not encouraging this, just mentioning to emphasize that the mechanism is in fact much simpler and much more controllable than it may seem on the surface.
I only wanted to allow one instance of my C extension class to be made, so I wanted to include the singleton module.
void Init_mousetest() {
VALUE mouseclass = rb_define_class("MyMouse",rb_cObject);
rb_require("singleton");
VALUE singletonmodule = rb_const_get(rb_cObject,rb_intern("Singleton"));
rb_include_module(mouseclass,singletonmodule);
rb_funcall(singletonmodule,rb_intern("included"),1,mouseclass);
### ^ Why do I need this line here?
rb_define_method(mouseclass,"run",method_run,0);
rb_define_method(mouseclass,"spawn",method_spawn,0);
rb_define_method(mouseclass,"stop",method_stop,0);
}
As I understand it, what that line does is the same as Singleton.included(MyMouse), but if I try to invoke that, I get
irb(main):006:0> Singleton.included(MyMouse)
NoMethodError: private method `included' called for Singleton:Module
from (irb):6
from C:/Ruby19/bin/irb:12:in `<main>'
Why does rb_include_module behave differently than I would expect it to? Also any tangential discussions/explanations or related articles are appreciated. Ruby beginner here.
Also it seems like I could have just kept my extension as simple as possible and just hack some kind of interface later on to ensure I only allow one instance. Or just put my mouse related methods into a module... Any of that make sense?
according to http://www.groupsrv.com/computers/about105620.html the rb_include_module() is actually just Module#append_features.
Apparently Module#include calls Module#append_features and Module#included. So in our C code we must also call included. Since clearly something important happens there.