@PatrickT 

No problem with the questions (si uno no pregunta, como aprende?).

Nothing special with four batch parameters. You need one for each command line parameter and they are assigned in increasing numeric order. So, unassigned batch parameters in "excess" make no harm, but fewer batch parameters than command line parameters mean that some of the latter are missed. So, you need enough batch parameters for covering the expected use, and four is a reasonable amount in most cases.

Certainly, there is no such thing as an execution group in the CLI (hence in input files).

I agree mostly with acer. In general, I have the code source in text files. The GUIs are more unreliable than text editors, editing code with them is more inconvenient, and the worksheet format is bloated. All these problems are like an order of magnitude more acute in Standard than in Classic. Then, I use the GUI only for simple tests or at an initial coding stage. And always Classic, unless there is an Standard specific issue. But if the piece of code grows beyond a few lines, I switch to the text form. On the other hand, I have implemented tools in Medit for launching the Classic or Standard GUI with the input file code. That is, I edit in text and then execute in the GUI. Of course, you can then save as a worksheet, but seldom I do it.

Medit itself is nice as an IDE but it is rather elementary as an editor (as it stands right now). So I use it for editing in medium size cases. For larger ones I switch to another (more powerful) programable editor, which, of course, I can call from within Medit.

What I disagree with acer is about the pain. I am pragmatic in these regards and always prefer the native way, be in Windows or Linux (donde fueres, haz lo que vieres - translations ?). I find it more efficient and natural. In case of need, native ports of unix utilities have been available for about 20 years, so it has never been much pain, at least for me.

@PatrickT 

No problem with the questions (si uno no pregunta, como aprende?).

Nothing special with four batch parameters. You need one for each command line parameter and they are assigned in increasing numeric order. So, unassigned batch parameters in "excess" make no harm, but fewer batch parameters than command line parameters mean that some of the latter are missed. So, you need enough batch parameters for covering the expected use, and four is a reasonable amount in most cases.

Certainly, there is no such thing as an execution group in the CLI (hence in input files).

I agree mostly with acer. In general, I have the code source in text files. The GUIs are more unreliable than text editors, editing code with them is more inconvenient, and the worksheet format is bloated. All these problems are like an order of magnitude more acute in Standard than in Classic. Then, I use the GUI only for simple tests or at an initial coding stage. And always Classic, unless there is an Standard specific issue. But if the piece of code grows beyond a few lines, I switch to the text form. On the other hand, I have implemented tools in Medit for launching the Classic or Standard GUI with the input file code. That is, I edit in text and then execute in the GUI. Of course, you can then save as a worksheet, but seldom I do it.

Medit itself is nice as an IDE but it is rather elementary as an editor (as it stands right now). So I use it for editing in medium size cases. For larger ones I switch to another (more powerful) programable editor, which, of course, I can call from within Medit.

What I disagree with acer is about the pain. I am pragmatic in these regards and always prefer the native way, be in Windows or Linux (donde fueres, haz lo que vieres - translations ?). I find it more efficient and natural. In case of need, native ports of unix utilities have been available for about 20 years, so it has never been much pain, at least for me.

@PatrickT 

What you are missing are the batch parameters that represent the parameters in the shell command line, like the input file name. My m15c.bat file looks like:

@echo off

<Maple 15 path>\bin.win\cwmaple %1 %2 %3 %4

where you should replace <Maple 15 path> with your actual path: C:\Program Files\Maple 15.

Remember that this batch file should be located in the executable path. I have a c:\bats directory in the path where the batch files are located.

I am old enough to have been using PCs in the DOS era for many years, when bat files were commonplace. So, I keep using them a lot even now as they are extremely useful for some purposes (as shell scripts are used on Linux). If this is not your experience, you may look at sites explainig batch files (I see that there are many), like this one that looks compact and useful.

@PatrickT 

What you are missing are the batch parameters that represent the parameters in the shell command line, like the input file name. My m15c.bat file looks like:

@echo off

<Maple 15 path>\bin.win\cwmaple %1 %2 %3 %4

where you should replace <Maple 15 path> with your actual path: C:\Program Files\Maple 15.

Remember that this batch file should be located in the executable path. I have a c:\bats directory in the path where the batch files are located.

I am old enough to have been using PCs in the DOS era for many years, when bat files were commonplace. So, I keep using them a lot even now as they are extremely useful for some purposes (as shell scripts are used on Linux). If this is not your experience, you may look at sites explainig batch files (I see that there are many), like this one that looks compact and useful.

Both lines work in Maple 15.01.

@PatrickT 

Yes, I am using Medit all the time, both on Windows and Linux. It is quite light and programmable, so that I am using it as a frontend for diverse CAS. Actually, I have used it only with shell scripts so far, but it can make profit of Lua and Python scripts also.

My settings for the tool item in Medit 1 for Maple 15 on Windows, with output going to the output pane are:

Files: *.mpl
Requires: Document
Save: Current Document
Type: Shell command
Input: None
Output: Output pane
Filter: Default
Script Box : m15c %DOC%

So, the differences are that the input mpl file is saved, and then the %DOC% label takes this value in the command line, where m15c is the name of the bat file for cmaple.exe that I have in the path (so that I can execute m15c file.mpl anywhere).

@PatrickT 

Yes, I am using Medit all the time, both on Windows and Linux. It is quite light and programmable, so that I am using it as a frontend for diverse CAS. Actually, I have used it only with shell scripts so far, but it can make profit of Lua and Python scripts also.

My settings for the tool item in Medit 1 for Maple 15 on Windows, with output going to the output pane are:

Files: *.mpl
Requires: Document
Save: Current Document
Type: Shell command
Input: None
Output: Output pane
Filter: Default
Script Box : m15c %DOC%

So, the differences are that the input mpl file is saved, and then the %DOC% label takes this value in the command line, where m15c is the name of the bat file for cmaple.exe that I have in the path (so that I can execute m15c file.mpl anywhere).

@PatrickT 

You should open already the Maple 20 wish list :)

If today's date were 28th December I would say: que la inocencia te valga! (translations ?).

@Markiyan Hirnyk 

In the interview to Gaston Gonnet linked here, you can read, in p.43:

[...]you release by time not by features, and thereafter we released by time not by features. Even the company nowadays, Maplesoft, is basically releasing by time not by features.

@Joe Riel 

Your answer should be for marram!

An issue with the function call representation generated by ToInert is that it shows the DAG as a tree. For instance, here:

dismantle[dec](x+f(x));
SUM(83807676,5)
   NAME(83716408,4): x
   INTPOS(3,2): 1
   FUNCTION(85639132,3)
      NAME(83889256,4): f
      EXPSEQ(85547240,2)
         NAME(83716408,4): x
   INTPOS(3,2): 1

it is clear from the memory addresses that there is a single x, while this is not evident from:

ToInert(x+f(x));
  _Inert_SUM(_Inert_NAME("x"), _Inert_FUNCTION(_Inert_NAME("f"),

        _Inert_EXPSEQ(_Inert_NAME("x"))))

@Joe Riel 

Your answer should be for marram!

An issue with the function call representation generated by ToInert is that it shows the DAG as a tree. For instance, here:

dismantle[dec](x+f(x));
SUM(83807676,5)
   NAME(83716408,4): x
   INTPOS(3,2): 1
   FUNCTION(85639132,3)
      NAME(83889256,4): f
      EXPSEQ(85547240,2)
         NAME(83716408,4): x
   INTPOS(3,2): 1

it is clear from the memory addresses that there is a single x, while this is not evident from:

ToInert(x+f(x));
  _Inert_SUM(_Inert_NAME("x"), _Inert_FUNCTION(_Inert_NAME("f"),

        _Inert_EXPSEQ(_Inert_NAME("x"))))

@PatrickT 

The only thing missing in this test input file was the directive $define for "defining" the macro marker2. So, with this addition:

$define marker2 := 1;
$ifdef marker1
1+1;
$endif
$ifdef marker2
2+2;
$endif

it produces the output that you have expected:

> 2+2;
                                       4

About loading the input file to the CLI from the OS command line, I find more practical to use a bat/script file in the path for the CLI executable, so that I can call it directly from the directory of the input file. Actually, I find it even more practical to call the CLI from within an IDE where I edit the source file, as I have shown here.

@PatrickT 

The only thing missing in this test input file was the directive $define for "defining" the macro marker2. So, with this addition:

$define marker2 := 1;
$ifdef marker1
1+1;
$endif
$ifdef marker2
2+2;
$endif

it produces the output that you have expected:

> 2+2;
                                       4

About loading the input file to the CLI from the OS command line, I find more practical to use a bat/script file in the path for the CLI executable, so that I can call it directly from the directory of the input file. Actually, I find it even more practical to call the CLI from within an IDE where I edit the source file, as I have shown here.

@PatrickT 

See also this thread on the include directive.

@PatrickT 

See also this thread on the include directive.