Add 'read' to naming scheme about nim

[Araq]

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]

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]

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