Thread Subject:

Matlab script filename has more than 1 dot

Is there a function that accepts a matlab filename/path as a string
argument and runs the file? I cannot simply type the filename because
it has multiple dots e.g. The.Matlab.Script.File.m. Outside of a
filename string argument, the dots are being interpretted as a field/
property delimiter in a struc (I'm using terminology from other
languages, so bear with me if I'm mutilating Matlab vernacular).

Sure, I can rename the file, but I got a whack of m-files with such
names. The dots separate version control meta-data, and I will have
to change them all if I want to run them at will without proliferating
copies everywhere. Also, the dots are a system I use for everything
that I do, so it would be nice if I don't have t change that just for
Matlab files.

On 5/29/2012 4:52 PM, Paul wrote:
> Is there a function that accepts a matlab filename/path as a string
> argument and runs the file? I cannot simply type the filename because
> it has multiple dots e.g. The.Matlab.Script.File.m. Outside of a
> filename string argument, the dots are being interpretted as a field/
> property delimiter in a struc (I'm using terminology from other
> languages, so bear with me if I'm mutilating Matlab vernacular).
>
> Sure, I can rename the file, but I got a whack of m-files with such
> names. The dots separate version control meta-data, and I will have
> to change them all if I want to run them at will without proliferating
> copies everywhere. Also, the dots are a system I use for everything
> that I do, so it would be nice if I don't have t change that just for
> Matlab files.

 From the Matlab doc's...

MATLAB function names have the same constraints as variable names.
MATLAB uses the first 31 characters of names. Function names must begin
with a letter; the remaining characters can be any combination of
letters, numbers, and underscores.
...
The name of the text file that contains a MATLAB function consists of
the function name with the extension .m ...

I don't think there's any way to get past the parser; the syntax is
defined as you note as something different than a function name so the
function you want would have the same problem.

--

On May 29, 6:47 pm, dpb <n...@non.net> wrote:
>On 5/29/2012 4:52 PM, Paul wrote:
>> Is there a function that accepts a matlab filename/path as a string
>> argument and runs the file? I cannot simply type the filename
>> because it has multiple dots e.g. The.Matlab.Script.File.m.
>> Outside of a filename string argument, the dots are being
>> interpretted as a field/ property delimiter in a struc (I'm using
>> terminology from other languages, so bear with me if I'm mutilating
>> Matlab vernacular).
>>
>> Sure, I can rename the file, but I got a whack of m-files with such
>> names. The dots separate version control meta-data, and I will
>> have to change them all if I want to run them at will without
>> proliferating copies everywhere. Also, the dots are a system I use
>> for everything that I do, so it would be nice if I don't have t
>> change that just for Matlab files.
>
> From the Matlab doc's...
>
> MATLAB function names have the same constraints as variable names.
> MATLAB uses the first 31 characters of names. Function names must
> begin with a letter; the remaining characters can be any combination
> of letters, numbers, and underscores. ... The name of the text
> file that contains a MATLAB function consists of the function name
> with the extension .m ...
>
> I don't think there's any way to get past the parser; the syntax is
> defined as you note as something different than a function name so
> the function you want would have the same problem.

I agree, for functions. I'm hoping (though not holding my breath)
that scripts aren't subject to the same constraint. For example, in
the unix "bash" command line shell, variables names are pretty
restrictive, but you can runy a file with any name using the "source"
command. (It doesn't mean the same thing in Matlab, already checked).

On 5/29/2012 6:36 PM, Paul wrote:
...

> I agree, for functions. I'm hoping (though not holding my breath)
> that scripts aren't subject to the same constraint....

Hope again; ain't gonna' happen. Scripts are a function w/o arguments
and return values which operate in the workspace environment but have
the same calling resolution.

As per usual, comparing any particular language w/ another is rife w/
similarities but expecting them is futile. Matlab is its own beastie;
afaik only Octave which is an attempt to be at least a partial clone is
even remotely near identical in behavior and even it has some
incompatibilities.

--

On May 29, 8:12

On 5/29/2012 7:57 PM, Paul wrote:
...

> I will go cry in my beer. Thanks.

Enjoy... :)

Best I can come up w/ to have your cake and eat it to would be to
substitute an underscore for the dots preceding the final .m suffix

Then if you keep the names under 31 characters, you can have a
version-name somewhat as you presently do, just not as multiple file
system extensions (you must have migrated from VMS :) ).

The way around the above limitation might be to reverse the order--put
the rev no first so identical characters run off the ass-end of the name
and aren't relevant for differentiation, anyway.

HTH...

--

On May 29, 10:35

On 5/29/2012 10:30 PM, Paul wrote:
...

> I fell back to using underscores. What is magical about 31
> characters? (I haven't touched VMS for quite some time. Mostly Unix.)

Only 31 characters in a function name are significant in Matlab(*).

I thought perhaps you gained the naming convention from the automagic
version cycle ;N appended under VMS.

(*) Unless it's been expanded in later versions; check current doc's to
be certain.

--

On 5/29/2012 10:47 PM, dpb wrote:
> On 5/29/2012 10:30 PM, Paul wrote:
> ....
>
>> I fell back to using underscores. What is magical about 31
>> characters? (I haven't touched VMS for quite some time. Mostly Unix.)
>
> Only 31 characters in a function name are significant in Matlab(*).
...

BTW, the same limit applies to variable name lengths...

--

dpb <none@non.net> wrote in message <jq45u9$2s0$2@speranza.aioe.org>...
> On 5/29/2012 10:47 PM, dpb wrote:
> > On 5/29/2012 10:30 PM, Paul wrote:
> > ....
> >
> >> I fell back to using underscores. What is magical about 31
> >> characters? (I haven't touched VMS for quite some time. Mostly Unix.)
> >
> > Only 31 characters in a function name are significant in Matlab(*).
> ...
>
> BTW, the same limit applies to variable name lengths...
>
> --

Only 31 characters? I think not. That was a limit in
early versions, but not the current one. The current
limit is 63 character names for variables.

>> MyVar12345678901234567890123456789012345678901234567890 = 7
MyVar12345678901234567890123456789012345678901234567890 =
     7
>> whos
  Name Size Bytes Class Attributes

  MyVar12345678901234567890123456789012345678901234567890 1x1 8 double

>> MyVar12345678901234567890123456789012345678901234567890 + 2
ans =
     9

John

On 5/29/2012 6:36 PM, Paul wrote:
...

> I agree, for functions. I'm hoping (though not holding my breath)
> that scripts aren't subject to the same constraint. For example, in
> the unix "bash" command line shell, variables names are pretty
> restrictive, but you can runy a file with any name using the "source"
> command. (It doesn't mean the same thing in Matlab, already checked).

BTW, I'll point out that similar restrictions occur in most
languages--C, Fortran, etc., have very similar naming rules that
punctuation in a name is used for structure fields or similar other
specific grammar parsing. Method hierarchies in languages that support
them have similar punctuation granted, but that's not a feature in Matlab.

I'll also note that the interpretive nature of Matlab is different than
compiled languages in that m-files are stored on disk and interpreted at
runtime instead of compiled and linked in compiled languages. The
resolution of a name in Matlab ends up finding the file by name w/ the
.m extension and is tied to the filename so strongly that the function
name inside the file is ignored so it doesn't even have to match the
called function name.

file testit.m

contains

 >> type testit.m

function thisasatest(x)
   % demonstrate the function name isn't significant to Matlab
   disp('thisisatest function in testit.m file')

 >> testit
thisisatest function in testit.m file

 >> thisisatest
??? Undefined function or variable 'thisisatest'.

 >>

Note that Matlab "knows nuthink" about a function 'thisisatest'

--

On 5/30/2012 6:44 AM, John D'Errico wrote:
...

> Only 31 characters? I think not. That was a limit in
> early versions, but not the current one. The current
> limit is 63 character names for variables.
>
...

Well, yes, that's why I told OP to check current doc's...

Are function names now 63, too?

--

On 5/30/2012 7:53 AM, dpb wrote:
> On 5/30/2012 6:44 AM, John D'Errico wrote:
> ....
>
>> Only 31 characters? I think not. That was a limit in
>> early versions, but not the current one. The current
>> limit is 63 character names for variables.
>>
> ....
>
> Well, yes, that's why I told OP to check current doc's...
>
> Are function names now 63, too?

Ah, ok, I see there's now _namelengthmax_ that returns length of all
Matlab identifiers. Not sure when was implemented but after my release.

--

"Paul" <paul.domaskis@gmail.com> wrote in message
news:bb4c4dba-6ff5-4131-adcc-cbf17dab494e@to5g2000pbc.googlegroups.com...
> Is there a function that accepts a matlab filename/path as a string
> argument and runs the file? I cannot simply type the filename because
> it has multiple dots e.g. The.Matlab.Script.File.m.

That is not a valid MATLAB identifier.

http://www.mathworks.com/help/techdoc/ref/isvarname.html

Yes, I know the name of that function implies it just applies to variable
names, but those rules also govern function, script, and class names. That
name violates the rule about identifiers being "character string of letters,
digits, and underscores."

> Outside of a
> filename string argument, the dots are being interpretted as a field/
> property delimiter in a struc (I'm using terminology from other
> languages, so bear with me if I'm mutilating Matlab vernacular).
>
> Sure, I can rename the file, but I got a whack of m-files with such
> names. The dots separate version control meta-data, and I will have
> to change them all if I want to run them at will without proliferating
> copies everywhere. Also, the dots are a system I use for everything
> that I do, so it would be nice if I don't have t change that just for
> Matlab files.

I'm not that familiar with different revision control systems, but what
revision control system uses that convention? [If you're using them as a
simple versioning system, like naming your files "myfile.1.m", "myfile.2.m",
etc. and you have lots of files, you may want to consider setting up a small
revision control system. There are a number that I've heard are small and
fairly easy to set up.]

http://en.wikipedia.org/wiki/List_of_revision_control_software

Some can even be used from within MATLAB through the source control
interface.

http://www.mathworks.com/help/techdoc/matlab_env/f7-5297.html

--
Steve Lord
slord@mathworks.com
To contact Technical Support use the Contact Us link on
http://www.mathworks.com

"dpb" <none@non.net> wrote in message news:jq572i$prh$1@speranza.aioe.org...
> On 5/30/2012 7:53 AM, dpb wrote:
>> On 5/30/2012 6:44 AM, John D'Errico wrote:
>> ....
>>
>>> Only 31 characters? I think not. That was a limit in
>>> early versions, but not the current one. The current
>>> limit is 63 character names for variables.
>>>
>> ....
>>
>> Well, yes, that's why I told OP to check current doc's...
>>
>> Are function names now 63, too?
>
> Ah, ok, I see there's now _namelengthmax_ that returns length of all
> Matlab identifiers. Not sure when was implemented but after my release.

That was introduced in MATLAB 6.5, release R13, when we increased the limit
from 31 characters to 63.

http://www.mathworks.com/help/releases/R14/techdoc/rn/matla15a.html#52143

--
Steve Lord
slord@mathworks.com
To contact Technical Support use the Contact Us link on
http://www.mathworks.com

On 5/30/2012 9:17 AM, Steven_Lord wrote:
> "dpb" <none@non.net> wrote in message
> news:jq572i$prh$1@speranza.aioe.org...
...

>> Ah, ok, I see there's now _namelengthmax_ that returns length of all
>> Matlab identifiers. Not sure when was implemented but after my release.
>
> That was introduced in MATLAB 6.5, release R13, when we increased the
> limit from 31 characters to 63.

One release past mine...

> http://www.mathworks.com/help/releases/R14/techdoc/rn/matla15a.html#52143

Which TMW in their limitless wisdom has blocked...

"Access to archived documentation is a benefit for licensed users of
MathWorks products."

Why/what on earth it would hurt or cost TMW is beyond me, but somehow
it's privileged information. :(

--

On May 30, 8:04 am, dpb <n...@non.net> wrote:
> On 5/29/2012 6:36 PM, Paul wrote:
>> I agree, for functions. I'm hoping (though not holding my breath)
>> that scripts aren't subject to the same constraint. For example,
>> in the unix "bash" command line shell, variables names are pretty
>> restrictive, but you can runy a file with any name using the
>> "source" command. (It doesn't mean the same thing in Matlab,
>> already checked).
>
> BTW, I'll point out that similar restrictions occur in most
> languages--C, Fortran, etc., have very similar naming rules that
> punctuation in a name is used for structure fields or similar other
> specific grammar parsing. Method hierarchies in languages that
> support them have similar punctuation granted, but that's not a
> feature in Matlab.
>
> I'll also note that the interpretive nature of Matlab is different
> than compiled languages in that m-files are stored on disk and
> interpreted at runtime instead of compiled and linked in compiled
> languages. The resolution of a name in Matlab ends up finding the
> file by name w/ the .m extension and is tied to the filename so
> strongly that the function name inside the file is ignored so it
> doesn't even have to match the called function name.
>
> file testit.m
>
> contains
>
> >> type testit.m
>
> function thisasatest(x)
> % demonstrate the function name isn't significant to Matlab
> disp('thisisatest function in testit.m file')
>
> >> testit
> thisisatest function in testit.m file
>
> >> thisisatest
> ??? Undefined function or variable 'thisisatest'.
>
> >>
>
> Note that Matlab "knows nuthink" about a function 'thisisatest'

I understand if we're talking about identifiers, but a command like
bash's "source" in effect redirects standard-in to a file. It is
meant to take a file name and pipe to an interpreter. It is not
related to workspace identifiers for functions or variables.

On May 30, 10:13 am, "Steven_Lord" <sl...@mathworks.com> wrote:
> "Paul" <paul.domas...@gmail.com> wrote:
>> Is there a function that accepts a matlab filename/path as a string
>> argument and runs the file? I cannot simply type the filename
>> because it has multiple dots e.g. The.Matlab.Script.File.m.
>
> That is not a valid MATLAB identifier.

No. Hence, I was seeking the equivalent of bash's "source" command,
which redirects stdin to a file and feeds it to the interpreter. That
in no way tries to treat the filename as an identifier.

> I'm not that familiar with different revision control systems, but
> what revision control system uses that convention? [If you're using
> them as a simple versioning system, like naming your files
> "myfile.1.m", "myfile.2.m", etc. and you have lots of files, you may
> want to consider setting up a small revision control system. There
> are a number that I've heard are small and
> fairly easy to set up.]
>
> http://en.wikipedia.org/wiki/List_of_revision_control_software
>
> Some can even be used from within MATLAB through the source control
> interface.
>
> http://www.mathworks.com/help/techdoc/matlab_env/f7-5297.html

I've had to use source control systems setup by others before. It's
heavy artillery for the quick and dirty that I'm seeking. The format
is usually Original.file.ext changed to
Original.file.YYYYMMDD.hhmm.ext. And outputs are
Original.file.out.YYYYMMDD.hhmm.txt. I'll just use underscores.
Thanks.

On 5/30/2012 3:07 PM, Paul wrote:
...

> I understand if we're talking about identifiers, but a command like
> bash's "source" in effect redirects standard-in to a file. It is
> meant to take a file name and pipe to an interpreter. It is not
> related to workspace identifiers for functions or variables.

But how can we be talking about anything other than identifiers when
referring to executing a Matlab m-file function/script? The only way
that can happen is for the Matlab interpreter to parse it (ignoring the
possibility of converting it to an executable and letting the OS execute
that, of course).

I'm confused how you can relate the two (Matlab script and an external
executable) or am I totally off in what you're driving at?

BTW, if we're right, S Lord's suggestion of a VCS instead of the
renaming option of killing the dots is _a_very_good_one_ (tm) indeed
(wish I'da thunk of it :) ).

--

On 5/29/2012 7:36 PM, Paul wrote:

> I agree, for functions. I'm hoping (though not holding my breath)
> that scripts aren't subject to the same constraint. For example, in
> the unix "bash" command line shell, variables names are pretty
> restrictive, but you can runy a file with any name using the "source"
> command. (It doesn't mean the same thing in Matlab, already checked).

If you really want to, you can read an entire script file into a char
array and then pass it to eval:

fid = fopen('my.badly.named.m.file','rt');
source = fread(fid,[1 inf],'*char');
fclose(fid);
eval(source)


--
Doug Schwarz
dmschwarz&ieee,org
Make obvious changes to get real email address.

On May 30, 4:18 pm, dpb <n...@non.net> wrote:
> On 5/30/2012 3:07 PM, Paul wrote:
>> I understand if we're talking about identifiers, but a command like
>> bash's "source" in effect redirects standard-in to a file. It is
>> meant to take a file name and pipe to an interpreter. It is not
>> related to workspace identifiers for functions or variables.
>
> But how can we be talking about anything other than identifiers when
> referring to executing a Matlab m-file function/script?

Apparently, you can't in Matlab. Whether or not it could be done was
what I was asking about.

> The only
> way that can happen is for the Matlab interpreter to parse it
> (ignoring the possibility of converting it to an executable and
> letting the OS execute that, of course).
>
> I'm confused how you can relate the two (Matlab script and an
> external executable) or am I totally off in what you're driving at?

It's done in shell scripting. I don't recall just off the top of my
head, but for some reason, this concept just doesn't seem that foreign
to me, so I've probably seen it in other scripting languages as well
e.g. perhaps for tool control.

On May 30, 4:38 pm, Doug Schwarz <s...@sig.for.address.edu> wrote:
> On 5/29/2012 7:36 PM, Paul wrote:
>> I agree, for functions. I'm hoping (though not holding my breath)
>> that scripts aren't subject to the same constraint. For example,
>> in the unix "bash" command line shell, variables names are pretty
>> restrictive, but you can runy a file with any name using the
>> "source" command. (It doesn't mean the same thing in Matlab,
>> already checked).
>
> If you really want to, you can read an entire script file into a
> char array and then pass it to eval:
>
> fid = fopen('my.badly.named.m.file','rt');
> source = fread(fid,[1 inf],'*char');
> fclose(fid);
> eval(source)

Thanks Doug. I think the most convenient way is to stick with proper
m-file naming convention. However, your code snippet is very
education.

"Doug Schwarz" <see@sig.for.address.edu> wrote in message
news:jq60gr$q3m$1@dont-email.me...
> On 5/29/2012 7:36 PM, Paul wrote:
>
>> I agree, for functions. I'm hoping (though not holding my breath)
>> that scripts aren't subject to the same constraint. For example, in
>> the unix "bash" command line shell, variables names are pretty
>> restrictive, but you can runy a file with any name using the "source"
>> command. (It doesn't mean the same thing in Matlab, already checked).
>
> If you really want to, you can read an entire script file into a char
> array and then pass it to eval:
>
> fid = fopen('my.badly.named.m.file','rt');
> source = fread(fid,[1 inf],'*char');
> fclose(fid);
> eval(source)

That will work for script files, but not for function or classdef files. In
that case, making a temporary copy (in TEMPDIR, for instance) and invoking
that temporary copy (as long as the function/class doesn't use any private
functions) is an option; but I'd prefer keeping the names of the files as
valid MATLAB identifiers, personally.


function varargout = callDotFile(thedotfile, varargin)
% Invoke like:
% [a, b] = callDotFile('my.file.with.dots.m', 1, 2);
% to essentially call:
% [a, b] = my.file.with.dots(1, 2);

% Copy the file to the temporary directory with a new name
newname = tempname;
[status, themessage, identifier] = copyfile(thedotfile, newname)
if ~status
    error(identifier, 'Unable to copy file to new directory. Error was: %s',
themessage);
end

% Make sure to delete the temporary copy when we exit (normally or via
error)
deletetempfile = onCleanup(@() delete(newname));

% Make sure to go back to where we were when we exit
P = pwd;
goback = onCleanup(@() cd(P));

% Go to that directory
[pathstr, thename] = fileparts(newname);
cd(pathstr);

% Run
fh = str2func(thename);
[varargout{1:nargout}] = fh(varargin{:});


Note that I haven't tried executing this, but something like it should work.

--
Steve Lord
slord@mathworks.com
To contact Technical Support use the Contact Us link on
http://www.mathworks.com

On 5/31/2012 8:30 AM, Paul wrote:
> On May 30, 4:18 pm, dpb<n...@non.net> wrote:
...

>> I'm confused how you can relate the two (Matlab script and an
>> external executable) or am I totally off in what you're driving at?
>
> It's done in shell scripting. I don't recall just off the top of my
> head, but for some reason, this concept just doesn't seem that foreign
> to me, so I've probably seen it in other scripting languages as well
> e.g. perhaps for tool control.

Yes, but you can't expect to execute a script that doesn't follow the
syntax of the scripting language whatever its source.

What you were asking for does as there's no way for Matlab to determine
it's a function name in the reference as opposed to a structure. (Now
whether TMW _could_ have changed the parsing rules to ignore anything
except whether the potential identifier ends in anything except '.m' for
a valid function name and not run into a bunch of other insurmountable
parsing problems I've not considered but they didn't.)

If you use the eval() route that Doug mentioned and Steven followed up
on wrt (and which I purposely avoided mentioning :) ) you can bypass the
invocation step but eval() really does lead to "issues"...

--

"dpb" <none@non.net> wrote in message news:jq89jl$mep$1@speranza.aioe.org...
> On 5/31/2012 8:30 AM, Paul wrote:
>> On May 30, 4:18 pm, dpb<n...@non.net> wrote:
> ...
>
>>> I'm confused how you can relate the two (Matlab script and an
>>> external executable) or am I totally off in what you're driving at?
>>
>> It's done in shell scripting. I don't recall just off the top of my
>> head, but for some reason, this concept just doesn't seem that foreign
>> to me, so I've probably seen it in other scripting languages as well
>> e.g. perhaps for tool control.
>
> Yes, but you can't expect to execute a script that doesn't follow the
> syntax of the scripting language whatever its source.
>
> What you were asking for does as there's no way for Matlab to determine
> it's a function name in the reference as opposed to a structure. (Now
> whether TMW _could_ have changed the parsing rules to ignore anything
> except whether the potential identifier ends in anything except '.m' for a
> valid function name and not run into a bunch of other insurmountable
> parsing problems I've not considered but they didn't.)

Consider that if we allowed multiple periods in a function name, you could
have a function file named x.foo.m and then execute this code:

x = struct('foo', 1);
y = x.foo(1)

and it would be ambiguous whether you intended y to be the first element of
the foo field of the struct array x or the result of calling x.foo.m with
the only input argument being the scalar 1. But that ambiguity would
probably be breakable by the rule that variable trumps function name:

http://www.mathworks.com/help/techdoc/matlab_prog/f7-58170.html#bresuvu-3

But if x.foo was allowable as a function name, why shouldn't it be allowed
as a variable name as well?

% Create the variable x.foo = 17 using some hypothetical syntax
x = struct('foo', 1);
y = x.foo(1)

Now we have an ambiguity between two variables -- is y the first element of
the field foo of the struct array x or is it the first element of the x.foo
variable? That's not so clear-cut a disambiguation. I can think of ways we
_could_ do that disambiguation, but I can also think of problems with those
methods as well. And now we're starting to get into Rube Goldberg space.

> If you use the eval() route that Doug mentioned and Steven followed up on
> wrt (and which I purposely avoided mentioning :) ) you can bypass the
> invocation step but eval() really does lead to "issues"...

I considered using EVAL in that example, but I knew I'd get called on it if
I did. Besides, STR2FUNC + function handle evaluation works in that scenario
just as well.

--
Steve Lord
slord@mathworks.com
To contact Technical Support use the Contact Us link on
http://www.mathworks.com

On 5/31/2012 12:58 PM, Steven_Lord wrote:
...

> Consider that if we allowed multiple periods in a function name, you
> could have a function file named x.foo.m and then execute this code:
>
> x = struct('foo', 1);
> y = x.foo(1)
>
> and it would be ambiguous whether you intended y to be the first element
> of the foo field of the struct array x or the result of calling x.foo.m
> with the only input argument being the scalar 1. But that ambiguity
> would probably be breakable by the rule that variable trumps function name:
>
> http://www.mathworks.com/help/techdoc/matlab_prog/f7-58170.html#bresuvu-3
>
> But if x.foo was allowable as a function name, why shouldn't it be
> allowed as a variable name as well?
>
> % Create the variable x.foo = 17 using some hypothetical syntax
> x = struct('foo', 1);
> y = x.foo(1)
>
> Now we have an ambiguity between two variables -- is y the first element
> of the field foo of the struct array x or is it the first element of the
> x.foo variable? That's not so clear-cut a disambiguation. I can think of
> ways we _could_ do that disambiguation, but I can also think of problems
> with those methods as well. And now we're starting to get into Rube
> Goldberg space.
...

Well, I was thinking of something in Goldberg space from the git-go; the
structure issues are clearly a pita if allow calling syntax that mimics
present.

I specifically was essentially saying was do the lookup to see if the
identifier string appending '.m' exists as an m-file and if so, just go
for it. Sorry way to run a railroad and stuff still probably breaks but
if doesn't try to parse field names, etc., that is clearly impossible
w/o some sort of such a special rule.

_NOT_ a good idea...not to be considered as remotely a suggestion; just
trying to get to Paul that afaict he's mixing up sourcing a piece of
code w/ the interpretation thereof because even in his shell scripts
there are syntax rules he can't break and expect it to run; he's just
seemingly ignoring that "problem/feature" (or we're still having a
_failure_to_communicate_ (tm) problem).

It's always fun to have these sidebars w/ you Steven even if they're
often of little real consequence... :)

--

On May 31, 1:58 pm, "Steven_Lord" <sl...@mathworks.com> wrote:
> "dpb" <n...@non.net> wrote in messagenews:jq89jl$mep$1@speranza.aioe.org...
>> On 5/31/2012 8:30 AM, Paul wrote:
>>> On May 30, 4:18 pm, dpb<n...@non.net> wrote:
>>>> I'm confused how you can relate the two (Matlab script and an
>>>> external executable) or am I totally off in what you're driving
>>>> at?
>>>
>>> It's done in shell scripting. I don't recall just off the top of
>>> my head, but for some reason, this concept just doesn't seem that
>>> foreign to me, so I've probably seen it in other scripting
>>> languages as well e.g. perhaps for tool control.
>>
>> Yes, but you can't expect to execute a script that doesn't follow
>> the syntax of the scripting language whatever its source.
>>
>> What you were asking for does as there's no way for Matlab to
>> determine it's a function name in the reference as opposed to a
>> structure. (Now whether TMW _could_ have changed the parsing rules
>> to ignore anything except whether the potential identifier ends in
>> anything except '.m' for a valid function name and not run into a
>> bunch of other insurmountable parsing problems I've not considered
>> but they didn't.)
>
> Consider that if we allowed multiple periods in a function name, you
> could have a function file named x.foo.m and then execute this code:
>
> x = struct('foo', 1);
> y = x.foo(1)
>
> and it would be ambiguous whether you intended y to be the first
> element of the foo field of the struct array x or the result of
> calling x.foo.m with the only input argument being the scalar 1. But
> that ambiguity would probably be breakable by the rule that variable
> trumps function name:
>
> http://www.mathworks.com/help/techdoc/matlab_prog/f7-58170.html#bresu...
>
> But if x.foo was allowable as a function name, why shouldn't it be
> allowed as a variable name as well?
>
> % Create the variable x.foo = 17 using some hypothetical syntax
> x = struct('foo', 1);
> y = x.foo(1)
>
> Now we have an ambiguity between two variables -- is y the first
> element of the field foo of the struct array x or is it the first
> element of the x.foo variable? That's not so clear-cut a
> disambiguation. I can think of ways we _could_ do that
> disambiguation, but I can also think of problems with those methods
> as well. And now we're starting to get into Rube Goldberg space.
>
>> If you use the eval() route that Doug mentioned and Steven followed
>> up on wrt (and which I purposely avoided mentioning :) ) you can
>> bypass the invocation step but eval() really does lead to
>> "issues"...
>
> I considered using EVAL in that example, but I knew I'd get called
> on it if I did. Besides, STR2FUNC + function handle evaluation works
> in that scenario just as well.

I'm not explaining this properly. An equivalent to the "source"
command in Bash would take a string as an argument. It would
correspond to a filename, not an identifier in the workspace. It
would then redirect stdin to that file, stream in text from that file
as if it was coming in from the keyboard, then return control to the
keyboard when done. The string argument for the filename is never
used as an identifier in the workspace. I agree that a function can
be written to do this, and the issues it would have would depend on
the language/environment that it is being realized in.

On 5/31/2012 1:37 PM, Paul wrote:
...

> I'm not explaining this properly. An equivalent to the "source"
> command in Bash would take a string as an argument. It would
> correspond to a filename, not an identifier in the workspace. It
> would then redirect stdin to that file, stream in text from that file
> as if it was coming in from the keyboard, then return control to the
> keyboard when done. The string argument for the filename is never
> used as an identifier in the workspace. I agree that a function can
> be written to do this, and the issues it would have would depend on
> the language/environment that it is being realized in.

Yeah, after my last posting while out digging tumbleweeds out from the
cedars (one of my _most_ favorite chores (not!) :) ) it dawned on me
where we had the disconnect.

eval() w/ a filename instead of a string, in essence.

I don't know if eval is essentially a trapdoor into the interpreter or a
subset but it might be a reasonable enhancement request...

I couldn't get past needing the interpreter to parse the call first in
my previous mindset, sorry.

--

On May 31, 4:33

On May 31, 4:33 pm, dpb <n...@non.net> wrote:
>On 5/31/2012 1:37 PM, Paul wrote:
>> I'm not explaining this properly. An equivalent to the "source"
>> command in Bash would take a string as an argument. It would
>> correspond to a filename, not an identifier in the workspace. It
>> would then redirect stdin to that file, stream in text from that file
>> as if it was coming in from the keyboard, then return control to the
>> keyboard when done. The string argument for the filename is never
>> used as an identifier in the workspace. I agree that a function can
>> be written to do this, and the issues it would have would depend on
>> the language/environment that it is being realized in.
>
> Yeah, after my last posting while out digging tumbleweeds out from the
> cedars (one of my _most_ favorite chores (not!) :) ) it dawned on me
> where we had the disconnect.
>
> eval() w/ a filename instead of a string, in essence.
>
> I don't know if eval is essentially a trapdoor into the interpreter or a
> subset but it might be a reasonable enhancement request...

So I was turning this over in my mind...I know of another example of
this feature is the "include" command. This question has been asked
before:

http://www.mathworks.com/matlabcentral/newsreader/view_thread/160868
http://stackoverflow.com/questions/1277613/how-do-i-emulate-include-behaviour-in-matlab

But when all you really want to do is include a file that contains a
bunch of global constants (or global statements that allow those
variables to be accessed from the context in question), programmatic
workarounds to the lack of an include/source command is dissuasive.

Anyway, it's quite late, and I'll put the enhancement request on the
to-do list for the days when I get out earlier.

"dpb" <none@non.net> wrote in message news:jq8cqk$vdc$1@speranza.aioe.org...
> On 5/31/2012 12:58 PM, Steven_Lord wrote:

*snip*

> Well, I was thinking of something in Goldberg space from the git-go; the
> structure issues are clearly a pita if allow calling syntax that mimics
> present.
>
> I specifically was essentially saying was do the lookup to see if the
> identifier string appending '.m' exists as an m-file and if so, just go
> for it. Sorry way to run a railroad and stuff still probably breaks but
> if doesn't try to parse field names, etc., that is clearly impossible w/o
> some sort of such a special rule.

That's the reverse of how identifier identification works now; variables are
at the top of the list, followed by functions. Reversing that would avoid
some of the problems that we've seen where people "poof" variables like
alpha, beta, or gamma into their workspaces and then become confused when
they receive "not enough input argument" errors.

http://www.mathworks.com/help/techdoc/ref/alpha.html

http://www.mathworks.com/help/techdoc/ref/beta.html

http://www.mathworks.com/help/techdoc/ref/gamma.html

The flip side of that (if I understand your suggestion correctly) would be
that because alpha.m, beta.m, and gamma.m exist, if those identifiers
appeared in your code they would ALWAYS be treated as calls to the functions
and you could not have those names as variables. That would be bad (the
first three Greek letters come up as variable names in
math/science/engineering problems fairly frequently) but it probably
wouldn't be terrible; worse would be the same situation with I.

http://www.mathworks.com/help/techdoc/ref/i.html

I think people would scream if they couldn't use i as a variable (especially
a loop variable) name because i.m exists.

> _NOT_ a good idea...not to be considered as remotely a suggestion; just
> trying to get to Paul that afaict he's mixing up sourcing a piece of code
> w/ the interpretation thereof because even in his shell scripts there are
> syntax rules he can't break and expect it to run; he's just seemingly
> ignoring that "problem/feature" (or we're still having a
> _failure_to_communicate_ (tm) problem).
>
> It's always fun to have these sidebars w/ you Steven even if they're often
> of little real consequence... :)

It is fun sometimes to conduct thought experiments about "What would happen
if you could do this in MATLAB ..." Plus I've created more than a few
enhancement requests (and reported bugs) from these types of discussions,
usually as a result of "I need to cite this section of the documentation ...
hmm, that's not as clear/thorough/correct as it could and should be." or
"According to the documentation this function should do what I need it to
... *type* *type* ... except it doesn't."

--
Steve Lord
slord@mathworks.com
To contact Technical Support use the Contact Us link on
http://www.mathworks.com

"Paul" <paul.domaskis@gmail.com> wrote in message
news:27566560-500a-4f31-bfe1-3915a35509bc@h10g2000pbi.googlegroups.com...
> On May 31, 1:58 pm, "Steven_Lord" <sl...@mathworks.com> wrote:
>> "dpb" <n...@non.net> wrote in
>> messagenews:jq89jl$mep$1@speranza.aioe.org...
>>> On 5/31/2012 8:30 AM, Paul wrote:
>>>> On May 30, 4:18 pm, dpb<n...@non.net> wrote:

*snip*

> I'm not explaining this properly. An equivalent to the "source"
> command in Bash would take a string as an argument. It would
> correspond to a filename, not an identifier in the workspace. It
> would then redirect stdin to that file, stream in text from that file
> as if it was coming in from the keyboard, then return control to the
> keyboard when done. The string argument for the filename is never
> used as an identifier in the workspace. I agree that a function can
> be written to do this, and the issues it would have would depend on
> the language/environment that it is being realized in.

I believe the EVAL function is about as close an equivalent to the source
command you're looking for that exists in MATLAB, and it's not a complete
equivalent. See Doug's message earlier in the thread and the caveats in my
response to his message.

--
Steve Lord
slord@mathworks.com
To contact Technical Support use the Contact Us link on
http://www.mathworks.com

"Paul" <paul.domaskis@gmail.com> wrote in message
news:1d22f545-0368-4c69-8bef-68822c70b61a@o3g2000pby.googlegroups.com...
> On May 31, 4:33 pm, dpb <n...@non.net> wrote:
>>On 5/31/2012 1:37 PM, Paul wrote:
>>> I'm not explaining this properly. An equivalent to the "source"
>>> command in Bash would take a string as an argument. It would
>>> correspond to a filename, not an identifier in the workspace. It
>>> would then redirect stdin to that file, stream in text from that file
>>> as if it was coming in from the keyboard, then return control to the
>>> keyboard when done. The string argument for the filename is never
>>> used as an identifier in the workspace. I agree that a function can
>>> be written to do this, and the issues it would have would depend on
>>> the language/environment that it is being realized in.
>>
>> Yeah, after my last posting while out digging tumbleweeds out from the
>> cedars (one of my _most_ favorite chores (not!) :) ) it dawned on me
>> where we had the disconnect.
>>
>> eval() w/ a filename instead of a string, in essence.
>>
>> I don't know if eval is essentially a trapdoor into the interpreter or a
>> subset but it might be a reasonable enhancement request...
>
> So I was turning this over in my mind...I know of another example of
> this feature is the "include" command. This question has been asked
> before:
>
> http://www.mathworks.com/matlabcentral/newsreader/view_thread/160868
> http://stackoverflow.com/questions/1277613/how-do-i-emulate-include-behaviour-in-matlab
>
> But when all you really want to do is include a file that contains a
> bunch of global constants (or global statements that allow those
> variables to be accessed from the context in question), programmatic
> workarounds to the lack of an include/source command is dissuasive.

Such a statement, were it to exist, would need to be carefully designed to
avoid the "poofing" problem that's been discussed on this newsgroup
frequently in the past.

If I needed to write a list of global constants, I'd probably write a
function that returns a struct array with those constants, call that
function once at the top of the function in which I want to use those
constants, and index into the structure.
For the use case described on Stack Overflow, a switchyard or having the
function return a struct array of function handles to the subfunctions
(which can then be invoked directly using those function handles) would be
the approaches I'd try first.

> Anyway, it's quite late, and I'll put the enhancement request on the
> to-do list for the days when I get out earlier.

Please do. From the length of this thread, it seems like something in which
you're very interested, and if it's that important to a user we should at
least consider it. [No guarantees as to when or if we will implement it,
though.]

--
Steve Lord
slord@mathworks.com
To contact Technical Support use the Contact Us link on
http://www.mathworks.com

On 6/1/2012 9:03 AM, Steven_Lord wrote:
...

> The flip side of that (if I understand your suggestion correctly) would
> be that because alpha.m, beta.m, and gamma.m exist, if those identifiers
> appeared in your code they would ALWAYS be treated as calls to the
> functions and you could not have those names as variables. That would be
> bad (the first three Greek letters come up as variable names in
> math/science/engineering problems fairly frequently) but it probably
> wouldn't be terrible; worse would be the same situation with I.
>
> http://www.mathworks.com/help/techdoc/ref/i.html
>
> I think people would scream if they couldn't use i as a variable
> (especially a loop variable) name because i.m exists.
...

It would fix the problem of overriding the imaginary i/j once and for
all, though, wouldn't it? :) That surely can't be all bad. <gd&r>

>> It's always fun to have these sidebars w/ you Steven even if they're
>> often of little real consequence... :)
>
> It is fun sometimes to conduct thought experiments about "What would
> happen if you could do this in MATLAB ..." Plus I've created more than a
> few enhancement requests (and reported bugs) from these types of
> discussions, usually as a result of "I need to cite this section of the
> documentation ... hmm, that's not as clear/thorough/correct as it could
> and should be." or "According to the documentation this function should
> do what I need it to .... *type* *type* ... except it doesn't."

Indeed, even off-the-wall stuff occasionally can lead to either an
insight or step forward...I was just throwing out something that would
have solved Paul's problem in this case at the top level knowing it had
all kinds of other problems (one of which might be that the code he
managed to execute given the rule would no longer actually run).

As a sidebar to the question is there an internal TMW formal Matlab
grammar/definition that would serve the purpose of a formal Standard in
C/Fortran/etc.? I've always wondered if that had ever happened or
whether it continues to evolve and behavior is discussed before
implementation obviously but is less formally defined.

The question relates to the comment I've made in the past on the
documentation; particularly the introductory part that is all expository
rather than definitive for a lack of better terms otomh to describe it.
  The new user gets some general rules but they tend to be scattered in
a narrative style in a discussion that is centered on how to do some
operation rather than expounding the language.

--

On Jun 1, 10:15 am, "Steven_Lord" <sl...@mathworks.com> wrote:
>"Paul" <paul.domas...@gmail.com> wrote:
>> So I was turning this over in my mind...I know of another example
>> of this feature is the "include" command. This question has been
>> asked before:
>>
>> http://www.mathworks.com/matlabcentral/newsreader/view_thread/160868
>> http://stackoverflow.com/questions/1277613/how-do-i-emulate-include-b...
>>
>> But when all you really want to do is include a file that contains
>> a bunch of global constants (or global statements that allow those
>> variables to be accessed from the context in question),
>> programmatic workarounds to the lack of an include/source command
>> is dissuasive.
>
> Such a statement, were it to exist, would need to be carefully
> designed to avoid the "poofing" problem that's been discussed on
> this newsgroup frequently in the past.
>
> If I needed to write a list of global constants, I'd probably write
> a function that returns a struct array with those constants, call
> that function once at the top of the function in which I want to use
> those constants, and index into the structure. For the use case
> described on Stack Overflow, a switchyard or having the function
> return a struct array of function handles to the subfunctions (which
> can then be invoked directly using those function handles) would be
> the approaches I'd try first.

Though it took a while to work through the new (to me) concepts in
your example, it has been very educational. It sent me on a foray
into anonymous, inline, and nested functions; the many blogs of Loren;
and the statements tempname, onCleanup, and fileparts.

 * Can't define functions within scripts other than anonymous
   functions

 * Anonymous & inline functions use the values of the variables in the
   host function in at the time that the inline function is defined

 * The visibility of variables (nested functions can see variables in
   the host workspace but not vice-versa) and the similar visibility
   of nested functions

However, I'm not clear on why this was necessary for function or
classdef files (the latter of which I have never used). Not that I
ever intend to do that, but just curious. Is it possible to explain
this briefly?

As for a function that returns a struct of constants, it smells a bit
like what I did in VBA, which was to use functions to fetch constants
in Excel spreadsheets (or representing some attribute in the Excel
environtment) to bring them into the workspace of the VBA function in
question. However, I soon found that it was a reasonably clean way of
providing generated constants in general. I don't have access to the
code right now, but I don't recall the exact reason why I had
aversions to actual global constants -- possibly it was based on
whether I wanted the spreadsheet user to be able to access the
constants. If so, it got generated by a function from a spreadsheet
entry.

Also, I my functions didn't return a collection of constants in a
struct, as you are suggesting. In my view (which is one of limited
experience), it seems to be a good way to collect names into a name
space (in effect). Did I understand your intent correctly in this
regard?

I've also saw your multiple references to poofing in this thread, so I
looked it up. Well, it ain't official Matlab terminology, so even
though I saw plenty of mention of the term, I only saw a anything that
resembled a definition in one of Loren's blogs. Correct me if I'm
wrong, but poofing is bringing identifier into existence in a body of
code without the identifier showing up on the left hand side of an
assignment in that same body of code. As I understand it, the problem
is that Matlab does a preliminary scan of a body of code to determine
the identifiers before executing the code, so variables brought into
existence via load or eval will be missed. I suppose the same goes
for variables that clobber existing variables via load or eval. This
can cause those variable to refer to the wrong thing.

If I got it right, then I can certainly see the reason for the best
practices for avoiding them. The only thing I don't understand is why
something so fundamental is not part of the formal documentation.

Now, I started using Matlab almost 20 years ago. As is blatantly
obvious, I ain't no expert. There are lengthy durations of time when
I don't use it, punctuated by short bursts of intense usage and
learning about it. I don't recall issues like poofing ever being a
problem back then. If I understood it correctly, the poofing problem
is intimately tied to Matlab's preliminary scan of a body of code
prior to execution. Would I be right in guessing that such
preliminary scanning was brought in sometime after 20 years ago, and
that its purpose was to boost execution speed by giving a heads up of
what will be executed, thus allowing for preparatory optimization? If
so, then I would subjectively put it in a class of semi-compiled code
(probably less so than VBA). This preliminary scanning also breaks
the former execution paradigm, in which poofing was not a problem.

If my speculations are correct, I can certainly see why a source/
include command is such a big deal in Matlab. The include command is
used in C/C++ as well, and it does all of its compilation after
pulling in content from the included file. No bookkeeping conflict
there. The source command is for bash (possibly [t]csh), which has
*no* compilation, so no poofing problem there either.

"dpb" <none@non.net> wrote in message news:jqaulr$fo0$1@speranza.aioe.org...
> On 6/1/2012 9:03 AM, Steven_Lord wrote:

*snip*

> As a sidebar to the question is there an internal TMW formal Matlab
> grammar/definition that would serve the purpose of a formal Standard in
> C/Fortran/etc.? I've always wondered if that had ever happened or whether
> it continues to evolve and behavior is discussed before implementation
> obviously but is less formally defined.

I'm going to have to answer "no comment" to that question. Sorry.

> The question relates to the comment I've made in the past on the
> documentation; particularly the introductory part that is all expository
> rather than definitive for a lack of better terms otomh to describe it.
> The new user gets some general rules but they tend to be scattered in a
> narrative style in a discussion that is centered on how to do some
> operation rather than expounding the language.

IMO the documentation has to walk a fine line. If it were too technical
few/none of our users would read it (leaving aside the question of whether
or not anyone reads it in its current form ;) and if it were too
non-technical it wouldn't be useful in learning how to use MATLAB. I think
the narrative style used by some of it (particularly the Getting Started
section) is designed to make it interesting enough to motivate people to
read it while still providing enough crunchy goodness to be worth reading.

I'm curious if there are other software packages whose documentation you
feel walks this line better than ours. But perhaps this is getting off the
main topic of this thread, so if you want to continue that discussion please
start another thread for that purpose.

--
Steve Lord
slord@mathworks.com
To contact Technical Support use the Contact Us link on
http://www.mathworks.com

"Paul" <paul.domaskis@gmail.com> wrote in message
news:910e43bf-8c3f-4bad-a91d-152f7e06e97e@t8g2000yqd.googlegroups.com...
> On Jun 1, 10:15 am, "Steven_Lord" <sl...@mathworks.com> wrote:
>>"Paul" <paul.domas...@gmail.com> wrote:

*snip*

> Though it took a while to work through the new (to me) concepts in
> your example, it has been very educational. It sent me on a foray
> into anonymous, inline, and nested functions; the many blogs of Loren;
> and the statements tempname, onCleanup, and fileparts.
>
> * Can't define functions within scripts other than anonymous
> functions

Correct.

> * Anonymous & inline functions use the values of the variables in the
> host function in at the time that the inline function is defined

Anonymous functions, yes. Inline functions, no.

> * The visibility of variables (nested functions can see variables in
> the host workspace but not vice-versa) and the similar visibility
> of nested functions
>
> However, I'm not clear on why this was necessary for function or
> classdef files (the latter of which I have never used). Not that I
> ever intend to do that, but just curious. Is it possible to explain
> this briefly?

Why what was necessary? Making variables in the function in which the nested
function is nested be included in the scope of the nested function?

> As for a function that returns a struct of constants, it smells a bit
> like what I did in VBA, which was to use functions to fetch constants
> in Excel spreadsheets (or representing some attribute in the Excel
> environtment) to bring them into the workspace of the VBA function in
> question. However, I soon found that it was a reasonably clean way of
> providing generated constants in general. I don't have access to the
> code right now, but I don't recall the exact reason why I had
> aversions to actual global constants -- possibly it was based on
> whether I wanted the spreadsheet user to be able to access the
> constants. If so, it got generated by a function from a spreadsheet
> entry.
>
> Also, I my functions didn't return a collection of constants in a
> struct, as you are suggesting. In my view (which is one of limited
> experience), it seems to be a good way to collect names into a name
> space (in effect). Did I understand your intent correctly in this
> regard?

Namespacing is one consideration; avoiding creating functions with 73
[arbitrarily chosen value] different output arguments (which if you needed
to add another constant would require adding a 74th output at the end, to
avoid breaking existing code) was another. People have enough trouble
remembering the ordering of the 10 input arguments of the FMINCON function;
forget about remembering the order of 73 output arguments! If you have a
function, say:

function data = physicalconstants
% http://physics.nist.gov/cuu/Constants/index.html
data.g = struct('value', 9.80665, 'units', 'm*s^(-2)');
data.c = struct('value', 299792458, 'units', 'm*s^(-1)');
% continue on with the rest of the values from that page

then all you need to remember is what name in the structure is used for what
constant. If you choose your field names appropriately, this is easy; if
not, you can look at the FIELDNAMES of the struct to refresh your memory.

> I've also saw your multiple references to poofing in this thread, so I
> looked it up. Well, it ain't official Matlab terminology, so even
> though I saw plenty of mention of the term, I only saw a anything that
> resembled a definition in one of Loren's blogs. Correct me if I'm
> wrong, but poofing is bringing identifier into existence in a body of
> code without the identifier showing up on the left hand side of an
> assignment in that same body of code. As I understand it, the problem
> is that Matlab does a preliminary scan of a body of code to determine
> the identifiers before executing the code, so variables brought into
> existence via load or eval will be missed. I suppose the same goes
> for variables that clobber existing variables via load or eval. This
> can cause those variable to refer to the wrong thing.

Yes.

> If I got it right, then I can certainly see the reason for the best
> practices for avoiding them. The only thing I don't understand is why
> something so fundamental is not part of the formal documentation.

Well, I think I have the credit/blame for introducing that term via
newsgroup postings, and I have no idea how that term would translate in the
Japanese documentation.

> Now, I started using Matlab almost 20 years ago. As is blatantly
> obvious, I ain't no expert. There are lengthy durations of time when
> I don't use it, punctuated by short bursts of intense usage and
> learning about it. I don't recall issues like poofing ever being a
> problem back then. If I understood it correctly, the poofing problem
> is intimately tied to Matlab's preliminary scan of a body of code
> prior to execution. Would I be right in guessing that such
> preliminary scanning was brought in sometime after 20 years ago, and
> that its purpose was to boost execution speed by giving a heads up of
> what will be executed, thus allowing for preparatory optimization? If
> so, then I would subjectively put it in a class of semi-compiled code
> (probably less so than VBA). This preliminary scanning also breaks
> the former execution paradigm, in which poofing was not a problem.

I don't know whether your guess is correct or not; it predates me at
MathWorks at least, which means that behavior has been present for over 11
years.

> If my speculations are correct, I can certainly see why a source/
> include command is such a big deal in Matlab. The include command is
> used in C/C++ as well, and it does all of its compilation after
> pulling in content from the included file. No bookkeeping conflict
> there. The source command is for bash (possibly [t]csh), which has
> *no* compilation, so no poofing problem there either.

--
Steve Lord
slord@mathworks.com
To contact Technical Support use the Contact Us link on
http://www.mathworks.com

On 6/4/2012 10:07 AM, Steven_Lord wrote:
> "dpb" <none@non.net> wrote in message
> news:jqaulr$fo0$1@speranza.aioe.org...
...
>> As a sidebar to the question is there an internal TMW formal Matlab
>> grammar/definition that would serve the purpose of a formal Standard
>> in C/Fortran/etc.? ...
>
> I'm going to have to answer "no comment" to that question. Sorry.

Why am I not surprised... :)

>> The question relates to the comment I've made in the past on the
>> documentation; particularly the introductory part that is all
>> expository rather than definitive for a lack of better terms otomh to
>> describe it. The new user gets some general rules but they tend to be
>> scattered in a narrative style in a discussion that is centered on how
>> to do some operation rather than expounding the language.
>
> IMO the documentation has to walk a fine line. If it were too technical
> few/none of our users would read it (leaving aside the question of
> whether or not anyone reads it in its current form ;) and if it were too
> non-technical it wouldn't be useful in learning how to use MATLAB. I
> think the narrative style used by some of it (particularly the Getting
> Started section) is designed to make it interesting enough to motivate
> people to read it while still providing enough crunchy goodness to be
> worth reading.
>
> I'm curious if there are other software packages whose documentation you
> feel walks this line better than ours. But perhaps this is getting off
> the main topic of this thread, so if you want to continue that
> discussion please start another thread for that purpose.

I don't know that I was real interested in further discussion in
sufficient depth to warrant a thread, Steven; as I don't really have a
clear solution to provide.

I think in general programming language reference manuals and user
guides do a better job of expounding the corners of the language syntax
than does the descriptive Matlab documentation because there is a formal
Standard that can be used as a normative text to ensure coverage of the
salient points translated to (more or less) user-language from the
"standardese" in which the Standard is (necessarily) written.

The individual function descriptions are basically ok with the
occasional lapse that is inevitable in either error or incompleteness
but those get some input.

I agree TMW has a daunting task given the size of the language as having
so many functions to document and overall does a pretty good job and
clearly the propensity was never for users to read the manual and that
has, I think, only gotten worse over time, unfortunately.

I know that's not a lot of specific help, sorry...I just thought that if
there were/is a formal standard (for lack of better term) perhaps the
same idea of ensuring the documentation of features/useage covers the
space therein might help. The other change or perhaps addition would be
to cover that language portion as a topic in itself thoroughly in a
linear fashion rather than mixing it up with the Getting Started
tutorial narrative that for obvious reasons tries to cover a lot of
ground but not get buried in minutiae. Yet it's that very detail that
often is what bites...

--


--

On Jun 4, 2:28 pm, dpb <n...@non.net> wrote:
> I don't know that I was real interested in further discussion in
> sufficient depth to warrant a thread, Steven; as I don't really have
> a clear solution to provide.
>
> I think in general programming language reference manuals and user
> guides do a better job of expounding the corners of the language
> syntax than does the descriptive Matlab documentation because there
> is a formal Standard that can be used as a normative text to ensure
> coverage of the salient points translated to (more or less)
> user-language from the "standardese" in which the Standard is
> (necessarily) written.
>
> The individual function descriptions are basically ok with the
> occasional lapse that is inevitable in either error or
> incompleteness but those get some input.
>
> I agree TMW has a daunting task given the size of the language as
> having so many functions to document and overall does a pretty good
> job and clearly the propensity was never for users to read the
> manual and that has, I think, only gotten worse over time,
> unfortunately.
>
> I know that's not a lot of specific help, sorry...I just thought
> that if there were/is a formal standard (for lack of better term)
> perhaps the same idea of ensuring the documentation of
> features/useage covers the space therein might help. The other
> change or perhaps addition would be to cover that language portion
> as a topic in itself thoroughly in a linear fashion rather than
> mixing it up with the Getting Started tutorial narrative that for
> obvious reasons tries to cover a lot of ground but not get buried in
> minutiae. Yet it's that very detail that often is what bites...

I don't have *broad* experience in languages, but my impression is
that proprietary languages aren't as rigorously specified as languages
that have been handed over to the public domain. I am also under the
impression that it takes a tremendous amount of effort to nail down
all the corners of a language, so it might not be feasible for a
commercial entity. And it may also work against the interest of a
commercial entity because it clearly defines the limitations of their
language implementation, and makes it easier to develop compatible
work-alikes. Finally, nailing down all of the language can tie the
commercial entities hands in terms of both evolving the language for
expanded capability or to fix pathological behaviour.

Just speculation on my part.

On 6/4/2012 4:47 PM, Paul wrote:

>
> I don't have *broad* experience in languages, but my impression is
> that proprietary languages aren't as rigorously specified as languages
> that have been handed over to the public domain.

Not all languages have international standards.

For example, c, c++, ada, Fortran, etc... each has
an ANSI and ISO committee or working group made up of
representatives or language specialist from many countries
and the language standard definition is part of this process.

The standard is reviewed every 5 or so years.

It takes years to update the standard and the result is a
document that describes the language in details.

Here is for example, the C ISO standard

http://www.open-std.org/jtc1/sc22/wg14/

C++ standard
http://www.open-std.org/jtc1/sc22/wg21/

Ada standard
http://www.open-std.org/jtc1/sc22/wg9/

etc..

'proprietary languages', since they does not have an
ANSI nor ISO standard, are left up to the owner companies
to define them in whatever form they finds right.

You might ask, why is there no ANSI or ISO language standard
for Matlab? I guess, it is up to Mathworks. Since it owns
Matlab, it only can decided on these things. But if it
'releases' Matlab, and then there becomes an ISO Matlab langauge
standard, then Mathworks might/will lose some of the control and
flexibility it has on making changes to Matlab.

--Nasser

On 6/4/2012 5:10 PM, Nasser M. Abbasi wrote:
...

> You might ask, why is there no ANSI or ISO language standard
> for Matlab?...

No, I don't ask that at all--it's obvious because it _is_ a proprietary
language.

I didn't (at least hopefully didn't) imply there was or should be an
open Standard; I simply asked if TMW had gone to the extent of trying to
formalize the language internally to something approaching that level of
formalism.

As Paul conjects (to coin a verb :) ), I also suspect they have
deliberately not done so to that level owing to those reasons.

--

On 6/4/2012 4:47 PM, Paul wrote:
...

> I don't have *broad* experience in languages, but my impression is
> that proprietary languages aren't as rigorously specified as languages
> that have been handed over to the public domain. I am also under the
> impression that it takes a tremendous amount of effort to nail down
> all the corners of a language, so it might not be feasible for a
> commercial entity. And it may also work against the interest of a
> commercial entity because it clearly defines the limitations of their
> language implementation, and makes it easier to develop compatible
> work-alikes. Finally, nailing down all of the language can tie the
> commercial entities hands in terms of both evolving the language for
> expanded capability or to fix pathological behaviour.
>
> Just speculation on my part.

Reasonable imo and pretty much agrees w/ my
thinking/conjecturing/guessing. I'm certain there's a pretty thorough
vetting but how formalized a specification is is clearly as Steven makes
clear, proprietary information and TMW reserves the right to modify as
they see fit at any time they deem it in their best interests to do so.

Of course, they can't just go hog-wild or the loss of a consistent
product will cost more than any possible gain but they don't have to go
through a stakeholders' process other than their own internal procedures.

It's a double-edged sword for their user-base, too...there's far more
and faster evolution than in a Standardized language but there's a
higher risk of loss of backward compatibility w/ a later revision.
That's been noted by some users here in the past.

--