coderofsalvation/powscript

the README.md example

coderofsalvation opened this issue · 12 comments

@fcard I've modified the README.md example to get it to work again. It almost works again, except for printing the version-property of a parsed json-object.

What were your initial ideas on this?
Array-notation or dot-notation to reference (nested) properties?

fcard commented

Currently, you can get values like so:

X={}
json_parse X '{"a": {"b": 1}}'

json_print X a b #> 1

json_value ${y:ref} X a b
echo $y #> 1 

I think we could add some syntactic sugar, but I dunno about making them either $obj[prop] or obj.prop.

The first makes things a lot complicated, since we would need to differentiate between normal arrays and json arrays, as they differ in semantics quite a bit.

Making it obj.prop would make it difficult to use strings with dots in them, and in general I don't think it mixes well with the rest of the language.

We could make it something like ${obj.prop}, but is json that important that we need syntax for it?

fcard commented

I took a look at the readme example and found out a few bugs in the json parser (all of which I have now fixed), and also realized that the compiled script doesn't have the shebang at the start, which is very annoying.. and we can't pass command line arguments to powscript file, also very annoying. They should be easy enough to fix, through.

With that out of the way, how about this for the example? (which uses the vararg feature I am proposing in #52)

require     'json'
require_cmd 'curl'

usage(app)
  local example_url="https://raw.githubusercontent.com/coderofsalvation/powscript/master/package.json"
  echo "
  $app <json keys...> --url <json file>

  Description:
    obtains and parses the json file given by the url,
  then prints the data corresponding to the received keys.

  Examples:
    $app version         --url '$example_url'
    $app repository type --url '$example_url'
    $app repository url  --url '$example_url'
  "


run(@keys -- url)
  if empty? url
    echo "Usage: $(usage myapp)"; exit
  data={}
  json=$(curl -s $url)
  json_parse data "$json"
  json_print data $keys[@]

run $@

Which we should be able to run like this:

powscript myapp.pow version --url "https://raw.githubusercontent.com/coderofsalvation/powscript/master/package.json"

But right now, we can do:

powscript -c myapp.pow -o myapp.bash
bash myapp.bash version --url "https://raw.githubusercontent.com/coderofsalvation/powscript/master/package.json"
fcard commented

Heehee. Maybe we could add an examples directory to have this and more like it readily available in the repo.

fcard commented

There are a few more things that need fixing in the readme:

  • Command Line Options: you can use powscript --help to check the updated options.
  • Interactive Mode: I now consider it robust enough to not be experimental anymore, plus the output looks different now.
  • Posix Mode: Powscript now does its own checking to identify unsupported features, plus I want to eventually allow all features to work in it, even arrays ;P

I will let you handle those while I focus on porting my fork's PRs to here, and maybe later I will send some more nitpicky suggestions :P

fcard commented

(oh, and the --interactive flag is now assumed when there are no other arguments, since that's how all interactive languages I know work)

fcard commented

Your example is a bit confusing in what it's supposed to be... I get you're showing off features, but to me it's very distracting.

fcard commented

The new example is way better, I really like it! The only suggestions I have (I keep finding things to nitpick, sorry ;-;) are:

  1. Since you already require the HOME variable, why not have require_env 'HOME' instead of require_env 'TERM'?
  2. You could change run(@args -- foo) to run(@args -- description), it makes the argument more descriptive. (in two ways!) You could then also change the usage to please pass (--description|-d) <string>, to demonstrate that keyword args also have shortcut versions.