-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add 'read' to naming scheme #61
Comments
I think it should be called 'readAll' instead. The implementation for 'readAll' for stdin should be very different from the version that can be implemented for proper files: For proper files we know how big the resulting string will be. IMO this suggests we should provide 2 different implementations depending on "tty". And do we really 'readAll' for stdin? Don't serious applications use the rdstdin module (GNU readline wrapper) anyway? |
Yeah, that implies
so I can pipe my syntax tree in there and replace it with the macros for some metaprogramming. I don't thik |
Tass, Your problems stem from the fact that you are not understanding clearly the distinction between compile-time and run-time code execution in Nimrod. When you write top-level statements like: import macros
echo parseExpr(readall(stdin)).lispRepr() ... Nimrod will treat them as run-time code, so it will attempt to do the following:
Meta-programming in Nimrod is all about compile-time code execution, so what you need is to move your code in an "evaluation context" - This would be code inside macros or computed expressions assigned to constant variables. For example, here is how you can print at compile-time the AST for a string of nimrod code: import macros
macro dumpStringAst(s: stmt): stmt =
echo s[1].strVal.parseStmt.lispRepr
dumpStringAst """
echo "hello world"
""" For this kind of purposes, it's usually more convenient to write a macro that takes a block: import macros
macro dumpLisp(s: stmt): stmt =
echo s[1].lispRepr
dumpLisp:
echo "hello world" UPDATE: This macro is now part of the standard library (see also macros.dumpTree) Currently, the evaluation engine is limited to executing only pure nimrod code (there is no access to functions imported from C). The result of this is that it's not possible to do general I/O inside macros. You have access to a function called There are number of planned remedies for this in the long-term:
If your goal is to have interactive shell where you can inspect various Nimrod AST trees, then you must augment the REPL shell to do this (i.e. |
62: add string fields for target command and extension r=saem a=saem - previously the were consts, and undocumtented, now they're funcs and marked for inlining - changed whitelist to - minor formatting to something less archaic minor items while looking into nim-lang#61. Co-authored-by: Saem Ghani <[email protected]>
Add 'read()' to the naming scheme, with the logic that it reads the whole stream until end of message or file. And add the methods for
TFile
to the stdlib.The text was updated successfully, but these errors were encountered: