Queries following APL64 March 2020 Update

This topic is specifically for discussions on the new APL64 Project currently in development. This topic is open for all to browse. However, to post, one must have a registered account on the APLDN forum only available to APL+Win licensee under a current APL+Win Subscription.

Moderators: Tech Support, phpbb_admin

Queries following APL64 March 2020 Update

Postby Ajay Askoolum » March 12th, 2020, 3:18 pm

1. Win32 API calls are NOT supported. Correct?
2. APL64's configuration file: what is its format? I am guessing that it won't be an INI format.
3. APL64 application configuration: One configuration file per workspace?
4. I do not see []FMT or similar in the list of new functions? Any plans to incorporate a new formatting function that works more intuitively, a little like C#'s String.Format?
Ajay Askoolum
 
Posts: 884
Joined: February 22nd, 2007, 2:16 am
Location: United Kingdom

Re: Queries following APL64 March 2020 Update

Postby Tech Support » March 20th, 2020, 1:05 pm

Ajay,

Thank you for taking the time to post your questions. Below are the answers to each of them:

1. Win32 API calls are NOT supported. Correct?

Win32 API calls are supported.

2. APL64's configuration file: what is its format? I am guessing that it won't be an INI format.

The APL64 Project's configuration file is in the XML-format.

3. APL64 application configuration: One configuration file per workspace?

It is not per workspace. There will be a default location for the placement of the APL64 Project configuration file. But it can be overriden when it is specified in the APL64 Project application's command line.

4. I do not see []FMT or similar in the list of new functions? Any plans to incorporate a new formatting function that works more intuitively, a little like C#'s String.Format?

You'll be pleased to learn that ⎕FMT is supported. However, we didn't comprehend your follow-up question on "a new formatting function that works more intuitively like C#'s String.Format". What would be helpful if you were to provide further explanation and detailed examples illustrating your ideas about making formatting more intuitive and we will be glad to consider them in the APL64 Project.
Tech Support
 
Posts: 1230
Joined: February 10th, 2007, 7:33 am
Location: Rockville, MD

Re: Queries following APL64 March 2020 Update

Postby Ajay Askoolum » March 20th, 2020, 6:00 pm

Thanks for the update.

I am delighted that APL64 will support Win32 APIs; in the next update perhaps, please include some examples of Win32 calls and how the calls are defined.

[]FMT has too much of a history and it might be better to leave it as is in order to eliminate the likelihood of breaking existing code.

A new formatting function could provide

1. The functionality of String.Format, see https://docs.microsoft.com/en-us/dotnet ... mework-4.8
2. String interpolation, see https://docs.microsoft.com/en-us/dotnet ... erpolation

With 2 above, if the fill values are arrays, I would expect the APL result to iterate. Let me explain.
Code: Select all
      Name←⊃'Ajay' 'Askoolum'
      Title←⊃'Mr' 'Sir'
[]newFMT "Dear {Title} {Name}}")

should produce

Dear Mr Ajay
...
Dear Sir Askoolum
Ideally, ... will be a character of user choice with []tcff as the default. A function delivering string interpolation will make output building much (less code intensive and) more intuitive.

With 1 above, if the values are arrays, the whole array should be included. An example:
Code: Select all
      []newFMT ('The schedule:',[]tcnl,⎕tclf),'{0},{1}' Title Name
      The Schedule

       Mr  Ajay
       Sir Askoolum
The infill variables are concatenated so that there is no need to specify their respective widths (for vertical alignment). Also, if the placeholders (i.e. {0}, {1}) specify formatting, the formatting should be applied implicitly.

I have provided a quick and rather basic response; I hope it makes sense.
Ajay Askoolum
 
Posts: 884
Joined: February 22nd, 2007, 2:16 am
Location: United Kingdom

Re: Queries following APL64 March 2020 Update

Postby Davin Church » March 21st, 2020, 11:11 am

Ajay, that kind of work can be done quite simply using a utility function - I've had such a function for decades (and in fact all my web-page software uses it to fill in dynamic data, for example). Granted, it would be convenient if it were a built-in function but it's not much of a stretch to do it yourself.
Davin Church
 
Posts: 651
Joined: February 24th, 2007, 1:46 am

Re: Queries following APL64 March 2020 Update

Postby Ajay Askoolum » March 21st, 2020, 6:20 pm

Hi Davin, granted that

a. these functionalities can be (easily) implemented in user defined functions
b. there is some merit in user implementation as these can be changed (adapted) to cope with special situations

However, the same applies to the 40 or so new functions l listed in the update document. I guess that these have been implemented for speed i.e. I would expect interpreter level functions to be faster than user implemented counterparts.

I dislike []fmt as it is not (for me) very easy to use and, by contemporary standards, it is deficient in several respects; that is, it has not seen an enhancements across several versions. APL64 provides a good opportunity to provide enhancements.

All applications incorporate some degree of output formatting: my preference is to have this at interpreter level rather than manage it independently.
Ajay Askoolum
 
Posts: 884
Joined: February 22nd, 2007, 2:16 am
Location: United Kingdom


Return to APL64 Project

Who is online

Users browsing this forum: No registered users and 7 guests

cron