Second thoughts on :This, :That, and :TheOther

[PaulMansour]

I am concerned about introducing :CharList or :Text to distinguish text files. Text files are likely to contain stuff like MarkDown, HTML, CSS, JavaScript, stuff that other apps are likely to want to read and write. It is going to be annoying at best and a showstopper at worst to have :Text and :End wrapping a markdown file, when collaborating with other people and other software.

What about revisiting Norbert’s suggestion of using extensions to determine the item type? So .txt would be used for vectors of text vectors. We might also consider .array or better yet, .aplan for general APL arrays and namespaces. We could introduce as many extensions as necessary, but I think these two are probably enough to get started.

Thus .dyalog would be reserved for things that Dyalog knows how to fix. Of course in the future that might include arrays, but that should be easy to switch over to if desired.

So .array is the most general, and then we have things like .txt and potentially .charmat, .string, etc., – though I don’t know if these are really needed. One thing that would occur is that if you manually created a .aplan file in the op sys, and then edited it in the session, Acre might write it out with a different extension – demoting the type if you will. I think this is OK.

We could also allow .json, though Acre would not write this out – it would be one-way. I think this is OK to.

As I write this, it occurs to me that any extension not recognized as something else should be treated as a txt file and brought in as a vector of vectors.

[norberturkiewicz]

It's too bad ⎕LOCK does not work with every item. We can set items created by ⎕JSON from .json files to locked and treat them as one-way objects.

      t←⎕ns''
      t.a←'test'
      ⎕lock 't'
DOMAIN ERROR
      ⎕LOCK't'

[PhilLast]

I never answered Norbert's suggestions a few weeks ago regarding this as I was expecting a meeting to dicuss it all that never finally took place. I have the feeling you are confusing workspace items with external files. The contents of APLSource are available to be edited outside of APL, to be compared by other sofware and managed by a SCM but are in a place in the hierachy determined entirely by where they will occur in the ns-tree in an APL session. If we want JSON, XML, CSV, COBOL, PDF or any other type of files they'll go outside the APLSource tree in the project.

[PaulMansour]

Phil, I see your point, but there is overlap I think. Specifically, I keep markdown files as vectors of text vectors, as APL items. It is very convenient to have these in APL, more than convenient, as they are really part of the app. No doubt I will have CSS and other text files as well that I want to be in the workspace. It will be unfortunate if we have to have :Text around these as I can then not just pass them around to other apps.

[PhilLast]

I understand the problem. You want acre to read them in on loading the project rather than having to code their loading separately within the project so they're there on startup. And why not?

For now acre reads only .dyalog files from the source-tree. It could read a selection of other types or anything. How is a .CSV instantiated into the ws for instance? As a nested matrix? Likewise JSON, XML &c. But once it's in the ws how will acre know the type to give it if it's changed in an editor? All we'll have is a name and a value. Not all lists of strings are markdown. Not all nested matrices are CSVs. Not all CR separated strings are JSON.

What I'm currently doing with this.dyalog starting with :What could as easily be this.what without the intrusive content. For that we could probably give all nameclasses and identifiably different array types a different file extension but the obvious ones wouldn't necessarily be what you want. .array .function .operator .namespace .class with maybe .charstring .charlist &c. What I've managed to get down to minimal parsing could disappear altogether.

But none of this gives you a .CSV or a .MD . Another reserved filename in the project folder could be filetypes.txt. It could just do a one-to-one mapping between array types and filetypes.

Within a project containing filetypes.txt as

:namespace
    charlist←'.MD'
    charstring←'JSON'
    ...
:endnamespace

all charlists are stored as-is as .MD; charstrings as .JSON; nested matrices as .CSV &c.

Not everything but maybe better than nothing.

[norberturkiewicz]

I can see wanting a name-value pair lookup table for errors. I can define a JSON file and have it loaded through Acre Desktop into a namespace. I don't think it's currently possible (or wise) for Acre to track these changes. However, as my comment above, I don't know if we can lock those items. @PhilLast would most likely need a lookup table of namespaces or items that do not get updated on fix.

Some things are just easier to edit in other tools JSON, HTML and MD but they're integral to the overall source.

[PaulMansour]

"I understand the problem. You want acre to read them in on loading the project rather than having to code their loading separately within the project so they're there on startup. And why not?

Not just that, I actually maintain all my markdown files in the workspace. This is where they are edited, They are an integral part of the project.

Anyway, I'm not concerned with Md or csv. It is .charlist that is the interesting one. it might be better named .txt, and that's all I want. I would only name it .txt because other apps will know what it is, more likely.

Bigger discussion about whether we should change all .dyalog to specific extensions.

Let's discuss via phone.

[PaulMansour]

This is settled. We have extensions indicating item type.