Skip to content
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

Closed
reactormonk opened this issue Nov 2, 2011 · 3 comments
Closed

Add 'read' to naming scheme #61

reactormonk opened this issue Nov 2, 2011 · 3 comments

Comments

@reactormonk
Copy link
Contributor

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.

@Araq
Copy link
Member

Araq commented Nov 2, 2011

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?

@reactormonk
Copy link
Contributor Author

Yeah, that implies stdin has to be a different type than / subtype of TFile. My reason foor that was

import macros
echo parseExpr(readall(stdin)).lispRepr()

so I can pipe my syntax tree in there and replace it with the macros for some metaprogramming. I don't thik readLine will do it here.

@zah
Copy link
Member

zah commented Nov 3, 2011

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:

  1. read string from stdin (at run-time)
  2. parse the string as nimrod code (at run-time) - In order for this to work, the whole Nimrod compiler have to embedded in your executable, something that's obviously undesirable.

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 slurp that will read the whole contents of a given file at compile-time.

There are number of planned remedies for this in the long-term:

  1. Integration of libffi in the evaluation engine that will allow calling arbitrary C functions
  2. compiling macros to native code in DLLs that will boost their performance besides solving this problem.

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. nimrod i).

@Araq Araq closed this as completed Nov 12, 2011
krux02 pushed a commit to krux02/Nim that referenced this issue Jan 11, 2022
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 <saemghani+github@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants