Hi Jiri,
Thank you for your insights on the prototype. These would have come up
later if not now, and that is the reason why I sent it early on. Here is my
response to your queries:
> 1)
> It seems to me that rather than a shell language in itself, your concept
so far
> looks to me like a regular script language with some rather limited
> interaction with
> the actual shell. What makes a shell language different from just
> plugging in Lua with
> some system() calls, is that the integration with shell internals is
> seamless. Things
> like file handling, environment variables, pipes and process management,
those
> are the important things, but you seem to be spending a lot of effort on
> the commonplace concepts, and much less on the shell-specific concepts.
> Maybe you could give more explanation and examples
> involving planned things you can't do with common scripting languages as
easily?
I think I might have come wrong here in explaining things. What I
understand is (correct me if wrong) - how a script be powerful enough to
manipulate system directly. For example - how do you get fd of a file, get
environment variables inside the script etc? Files - Open it, close it etc.
HLang library functions are how I think it should be implemented. Here is
what was written on the website:
*The architecture of HLang execution is simplistic, it first reads the AST
root node and tries finding the function to call (initially main). This can
be tweaked to look beyond - to run commands written in C if the function
the script is trying to call is not defined. For sake of simpliciy and
segregation, these functioncall will have a prefix of HL_. For example, for
finding the number of arguments, HL_ARGLEN() may be called, for string
comparison or concatenation HL_STCMP() or HL_STRCAT() may be called. This
allows for fast execution of functions and do not require AST traversal.*
Kindly extend these ideas of libraries to think what all can a library
function do -it actually is a C code fully capable of connecting with
system with separate functions to change the way arguments are passed in C
and provided back to scrips. Let me give you an example, how you might
gather the path variable from the env_server and get it inside the script:
You may write in script something of the form *declare $var =
HL_GETENV("path"); *When the executor system sees this function call, it
searches the same in the AST function list. However, since there is no
definition of the function in the script, the interpreter may think this is
a library function. Hence what it does now, is it changes all the arguments
to the way that particular C functions may need (here, since HL_GETENV,
requires string itself, not much needs change) and asks for execution of
such a C function (already compiled during full interpreter compilation). A
C module is then invoked. Since it is C code, it can do anything - talk to
vfs, talk to env server etc. It gathers that data and after that, the
interpreter converts the result (in this case string returned by env
server) into appropriate "HLang specific format"- strings. Technically $var
declaration never gets to know whether it actually called a script function
or something else. It is the C function which implements HL_GETENV that
needs to do all the tasks of connecting with vfs/env etc.
This concept brings to one more thing... since the C implementations of
libraries can directly talk to vfs and do all things behind, how do
shellecho like *<% mkdir newfolder >* are handled - using such internal
implementations of C libraries or any other way? I would say there are two
ways of handling this - after making the substitution in these shell
commands like *<% mkdir {$var} >* , we may send this for execution to bdsh
- or handle it ourselves and talk to system directly - using self
implemented mkdir and a list of other commands. I thought over it and here
is what I decided finally (I may be wrong) - Send all such execution
requests to bdsh - this allows a few things - for one, the interpreter
would never have to worry about implementations of redirects and pipes,
since they will be handled the way bdsh handles the current commands of
such types. Any output request that you may need from such a command can be
easily done - whenever HLang calls bdsh - it asks to save any outputs to a
file and send it back to interpreter (through IPC or other ways). This data
(outputs) can be gathered and brought back into the script using again - a
library function designed specifically for this - something like *declare
$var = HL_STDOUT("<% cat helloworld.cpp | grep hello >"); *This command
calls library function - which internally calls shellecho (shell.c) with a
message notifying that output may be required back - this is then sent to
bdsh and output is captured and given back to HLang (obvious modifications
are needed in BDSH). This frees up the language from worrying about pipes
and makes use of available infrastructure. However, this is not maybe what
some of you want - given BDSH is something you want changed. In that case,
HLang can itself handle execution fully without bdsh - just it would need
another module that services shell.c and implements all commands such as
mkdir, cat etc. Also in that case, the syntax never changes - you still use *<%
mkdir {$var} > *without worrying whether it goes to bdsh or to internal
HLang implementation of mkdir.
I would like to say these were the many reasons why everything in HLang is
a string - they can virtually store any kind of data, it is just extra
trouble to get them in a particular format. However, this allows to be sure
about very little requirement changes when we consider the future data
storage scenarios. And also, I treat these library functions as the primary
functionalities that HLang may provide - the other present things
(constructs and all) are just aids for that.
However, I can be really wrong here, I may be missing something that you
really want me to answer or the system to do - can u be a bit more specific
on your requirements - the kind of things you want interpreter to do and
also how to do it - talking through bdsh or straight to for example vfs and
pipefs through internal implementation. Also did I answer the issue
correctly? do u want me to elaborate? Did you like some ideas, or do you
hate something? Or do you want me do add something to the core language
itself - and not as auxiliary functions. *Kindly help me get these things
correct early on - this is what I deem to concentrate upon in next
prototype. :-)*
> 2)
> Your syntax is somewhat unorthodox. In particular, using 'is' keyword to
define
> key-value map pairs seems rather strange. Are you drawing inspiration
> from any existing language? Perhaps it would be better to stick with
> syntaxes that
> are familiar to your audience already; C/C++, Java, Python, etc. are all
> worthy of being inspired by, syntax-wise.
Sure, if it is "is" that bothers, it can easily be changed to = or even =>
if u want - it just needs change in lexer and parser grammar right now.
What else syntax wise do u want me to change? I would really like to hear
on this.
> 3)
> The website doesn't contain much detail on how any of it works. For
> example, what happens if you try to do arithmetic on a variable that's
> a random text?
> A more prescriptive documentation of your design would help others
> identify possible flaws early on. History tells us that it's very
> easy to lock all future use into a particular flawed choice made early
> on (example: all of unix ecosystem).
>
> ___________________________________________
I understand that documentation is not proper: there were a few reasons for
this: for first, the system is a bit more complex than it looks and
explaining everything at this point when the actual choices are not locked
will be a waste of time, especially when a heavy changes may be imminent. I
expect this and therefore kept documentation to a bare minimum. For
specifics of what happens when we try arithmetic with text string: the
interpreter returns 1 - unsuccessful. However how it does that can be
easily done in a few ways: kindly read solve_expression group of commands
(executor.c) (simply put, currently atol() is used for string to long
conversion, very wrong indeed for cases like decimal points, but would
correct them for sure in final one, and there are obviously many issue that
needs addressing right now - for example, interpreter has problem of memory
leaks now, will be solved eventually - i am currently concentrating on
functionalities). However, once everything is sorted design wise, and a
near perfect roadmap is made, I would be more than happy to document each
and every component of the system, kindly forgive me on this right now.
I know this is not a specific problem u ask, there will be many more. I
therefore request u to kindly provide with a set of questions u want me to
answer. It would be easier to talk about specifics rather than generics.
Thank you for taking your time Jiri,
Awaiting reply,
Supragya Raj
_______________________________________________
HelenOS-devel mailing list
[email protected]
http://lists.modry.cz/listinfo/helenos-devel
