Hi Juergen / Elias, Please see my comments below also...
On Sunday, March 30, 2014 6:06 AM, Juergen Sauermann <[email protected]> wrote: Hello Harteg, please see my answers inline below... /// Jürgen On 03/29/2014 09:08 PM, Harteg Wariyar wrote: Hi. I just downloaded gnu apl1.3, running it on os-x mavericks. Took >a little bit of thinking and tinkering to get it up, but I have been waiting >to be able to run apl on the mac, so quite happy about that! > > I am not familiar with Apple products, but maybe Peter's nice document doc/APL-on-Macintosh.pdf could have helped? [Harteg: Yes, it definitely helped. Still, quite a bit of steps and few areas where I stumbled a bit.] One question - I was looking to interface with my file system - I see that >" )host " is implemented, but is there a []host - like command as well? >I tried []sh, []cmd, []host, but none of them seem to work. > >e.g. If I want to get "ls" of my system into a matrix, and begin parsing it, >is there a way? > > > I believe the above ⎕ functions are from some other APL interpreter. GNU APL has only implemented the ⎕ functions defined in IBM APL2 and in the ISO standard. In IBM APL2 you would do things like the above via AP100 (see src/testcases/AP100.tc for an example. [Harteg: ok, I took a look, but not sure if it can do what I am looking for e.g. OS←'ls' apl-1.3 files test1.apl but... mat1←OS←'ls' apl-1.3 files test1.apl mat1 ls Is there a way to have the ls (or shell command) output get saved in a variable? ] In GNU APL you also have the FILE_IO native function, see src/testcases/FILE_IO.tc for an example. [Harteg: Even this seems to be giving me a problem. 'lib_file_io.so' ⎕FX 'FILE_IO' 0 FILE_IO VALUE ERROR FILE_IO Not sure what I am doing wrong... ] [] >I am really happy to see a way to create apl code in vi (a little problem with >the >layout in that the Esc key is mapped to something - I will need to look into >that) >and load it via apl -f aplfile.apl. But is there a way to load this when I am >already in >apl via a [] system function ? > > >Also, it looks like there is currently no support for native files []nread, >[]ntie functionality? > > > Same as above. Currently you can )DUMP a workspace in a format that can be read back with apl -f. I could think about extending )COPY so it understands .apl files from )DUMP. I have added that to my TODO list. Otherwise, FILE_IO is the way to go. [Harteg: that would be fine. If you could implement []CY system function to copy or load this kind of file, that would be really nice, as it would enable loading of apl code libraries created in an external editor within apl functions I create. Kind of like #include or #import in other languages ] [] >as for bugs, I have one at the moment: >When I launch mac terminal with apl font, my font is black. Once I quit apl, >with )off, my font >is now gray. And when I restart apl, it is still light gray unlike the first >time I ran apl. Not sure why. >Upon starting a new terminal session, it's fine again. > > > Sounds like wrong ESC sequences for colors. Check your preferences file. [] >I do have suggestions for things I am looking for in apl that aren't typically >there - if interested, > >please let me know and I can organize my thoughts on this. > >e.g. localize variables by default (no side effects), multi-function scripts, >pass-by-value C-style structures. > > > I am rather sceptical of non-standard "improvements" of APL. I have seen many such extensions in other interpreters and languages. Very few of these extensions have really convinced me, though. I also believe that too many different extensions in different APL interpreters split an already small community of APL users into even smaller fractions. I understand that in the past this was (thought to be) needed by commercial vendors to distinguish their APL interpreter from those of their competitors. But the overall effect of that may have harmed APL more than it has helped. So, don't expect too much from GNU APL in that direction. [Harteg: Certainly, it would be best to understand your vision for GNU APL, and we can see from there] > > > >Anyway, you are doing wonderful work! >Thanks again and looking forward to your response, > > > - Harteg > > >
