You can take a program in your language and translate it fairlydirectly into C, albeit some parts will be ugly or non-idiomatic.
You can take a old-style C program, with some restrictions, andtranslate it fairly directly into your language.
You can take a old-style C program, with some restrictions, andtranslate it fairly directly into your language.
David Brown:
You can take a program in your language and translate it fairlydirectly into C, albeit some parts will be ugly or non-idiomatic.
This can work, because I've done it, but there are still quite a few problems, such as UB, limitations or omissions in C, or needing to
cajole C compilers into accepting my code.
You can take a old-style C program, with some restrictions, andtranslate it fairly directly into your language.
Targetting a lower-level language is easier than one higher level than
your source language.
Mine is a little higher level than C, so is a little more challenging.
It can be done of course, depending on how crudely you want to express
the original code.
But let's go through some of them ('M' is my language):
(TLDR: see end)
* C uses nested include files. M has 'include', but C's includes are
used for module headers. M has a proper module system. You really need
do quite a lot of work to eliminate module headers from C, and express
things as M modules
* Exported variables must be done properly, with an 'owner' module.
Imported names must not be directly visible in M source; only via a
module that exports them. This applies to functions, variables, types,
enums, records, named constants
* Then there's C's macro system, for which there is no equivalent. You
can try preprocessing before conversion, but the result can be
gobbledygook. Not suitable for a one-time translation. Alternatively you
can go through each macro and see how it might map to the M language.
You will find it just as much work as eliminating macros from C code to
end up as still-readable and maintainable C code.
* M has no conditional code blocks (this stuff is taken care of at the
module level)
* For every non-static module-level function or variable in C, you need
to remember to mark it as 'global' or 'export'.
On 03/12/2022 21:17, Bart wrote:
David Brown:
You can take a program in your language and translate it fairlydirectly into C, albeit some parts will be ugly or non-idiomatic.
This can work, because I've done it, but there are still quite a few
problems, such as UB, limitations or omissions in C, or needing to
cajole C compilers into accepting my code.
No, that would just be poor translation from your code to C.
;You can take a old-style C program, with some restrictions, andtranslate it fairly directly into your language.
I don't understand what you mean here. Do you mean that in M, a
"module" is a single file that contains both an "interface" section and
an "implementation" section, like in Pascal, rather than having separate "interface" files and "implementation" files, like in Modula-2 ? This
is, of course, perfectly fine. The translation to C basically consists
of putting the "interface" part in "file.h" and the implementation part
in "file.c".
A modular system must always support nested imports (or "includes" in C parlance). Otherwise the interface part of Module A could not make use
of types or other definitions from Module B.
(Translating jumbled or poorly structured C code into your language
would be harder - after all, it is possible to write a chaotic mess with
C include files.)
* Exported variables must be done properly, with an 'owner' module.
Imported names must not be directly visible in M source; only via a
module that exports them. This applies to functions, variables, types,
enums, records, named constants
Again, I don't see the sense in what you are saying. The names /must/
be visible in order to use them. The /definitions/ behind the names can
be hidden.
Now I am mixed up. Are we translating your M code to C, or C code to M?
Macros in C can be used well to write clearer code, and that should be
fine to translate to your language (we are talking manual translation,
not automatic transcompilation - if you were doing that, you'd do it
from the C after pre-processing).
On 04/12/2022 16:30, David Brown wrote:
On 03/12/2022 21:17, Bart wrote:constructs that don't tranlate; then it needs to dumbed down.
David Brown:
You can take a old-style C program, with some restrictions, andtranslate it fairly directly into your language.
*** This part was about translating from C to my M language ***
I don't understand what you mean here.? Do you mean that in M, a
"module" is a single file that contains both an "interface" section and
an "implementation" section, like in Pascal, rather than having separate "interface" files and "implementation" files, like in Modula-2 ?? This
is, of course, perfectly fine.? The translation to C basically consists
of putting the "interface" part in "file.h" and the implementation part
in "file.c".
* Exported variables must be done properly, with an 'owner' module.
Imported names must not be directly visible in M source; only via a
module that exports them. This applies to functions, variables, types,
enums, records, named constants
Again, I don't see the sense in what you are saying.? The names /must/
be visible in order to use them.? The /definitions/ behind the names can
be hidden.
In a C module that imports function F, the declaration (sometimes, definition) of F must exist in the translation unit. (What you get if
you preprocess that source module, flatten all the includes etc.)
In the M module that imports function F, the definition of F never
appears in the source for that module.
The compiler will find it by searching the namespaces of the imported modules.
(Actually, in the latest version, you won't see the name of the imported module either; that information is centralised.)
Now I am mixed up.? Are we translating your M code to C, or C code to M?
No this, is C to M now.
There are all sorts of problems involved with macros.
In short, doing this manually is just impractical (except for stylised,
very conservative C like I might write); it can be easier to rewrite.
Doing it programmatically has all sorts of issues too.
Macros in C can be used well to write clearer code, and that should be
fine to translate to your language (we are talking manual translation,
not automatic transcompilation - if you were doing that, you'd do it
from the C after pre-processing).
That doesn't work. For a start it will flatten all enumerations and
defines into literals; you need to preserve those.
Bart <bc@freeuk.com> wrote:
(Actually, in the latest version, you won't see the name of the imported
module either; that information is centralised.)
You mean that it impossible to compile a module without info from
central registry? For me it means that registry is now part of
your source.
Regarding C, in well written
In short, doing this manually is just impractical (except for stylised,
very conservative C like I might write); it can be easier to rewrite.
Well, if code if _really_ badly written or trivial, then independent
rewrite may be best way. OTOH, in many cases one can do "limited"
rewrite: write code that performs "the same" computations as code
in other language. "The same" includes 1-1 correspondence of variables
and fields in data structurs. Such limited rewrite can be 5-10
times faster than writing code from scratch, so in this sense
translating from one language to different language is easy,
it is much less effort than writing from scratch. Of course,
this assumes that code is doing something interesting, for trivial
code you are just doing with bulk and following original is of no
help.
Doing it programmatically has all sorts of issues too.
If you want fully automatic translation that preserves meaning,
then I would expect ugly and inefficient code as the result.
The fist issue that comes to mind is name mangling: since your
languages is case insensitive one may be forced to change some
C names to avoid clashes.
Concerning macros, you somewhat ignore one obvious solution:
implement a preprocessor for your language so that you
can translate C macros into macros for your preprocessor.
Macros in C can be used well to write clearer code, and that should be
fine to translate to your language (we are talking manual translation,
not automatic transcompilation - if you were doing that, you'd do it
from the C after pre-processing).
That doesn't work. For a start it will flatten all enumerations and
defines into literals; you need to preserve those.
"doesn't work" depends on your goal. If goal is to get running
executable as output from your compiler (IIUC "automatic
transcompilation" and the following text up to closing
parenthesis covers this case), then I see no problem
that expansion would cause.
s to get idiomatic code
in your language, then you need to be more creative. IME most
C macros are rather simple ones, to get effect of named constants
and to inline code, those can be translated to constructs of
your langage.
On 07/12/2022 17:47, antispam@math.uni.wroc.pl wrote:
Bart <bc@freeuk.com> wrote:
(Actually, in the latest version, you won't see the name of the imported >> module either; that information is centralised.)
You mean that it impossible to compile a module without info from
central registry? For me it means that registry is now part of
your source.
You can't compile a single 'module'; you compile the whole program. The
info that describes the module layout is at the top of the lead module,
which typically contains only module info.
So yes it can be considered part of the source, but is really
intermediate info between compiler, and source code proper.
Other languages may use command parameters, @ files, makefiles, or
untidy collections of 'import <module>` at the top of every module, that
need constant maintenance.
Regarding C, in well written
?
In short, doing this manually is just impractical (except for stylised,
very conservative C like I might write); it can be easier to rewrite.
Well, if code if _really_ badly written or trivial, then independent rewrite may be best way. OTOH, in many cases one can do "limited"
rewrite: write code that performs "the same" computations as code
in other language. "The same" includes 1-1 correspondence of variables
and fields in data structurs. Such limited rewrite can be 5-10
times faster than writing code from scratch, so in this sense
translating from one language to different language is easy,
it is much less effort than writing from scratch. Of course,
this assumes that code is doing something interesting, for trivial
code you are just doing with bulk and following original is of no
help.
Doing it programmatically has all sorts of issues too.
If you want fully automatic translation that preserves meaning,
then I would expect ugly and inefficient code as the result.
The fist issue that comes to mind is name mangling: since your
languages is case insensitive one may be forced to change some
C names to avoid clashes.
That would be a trivial matter: names can have a backtick prepended that preserves their case. But I wouldn't want to work with such source code: having to be case-sensensitive /and/ having the backtick. Name mangling
has the same problems.
This only works if the output is intermediate code that no one ever
sees. However compiling C via intermediate M is not a useful execise.
Concerning macros, you somewhat ignore one obvious solution:
implement a preprocessor for your language so that you
can translate C macros into macros for your preprocessor.
That's not a solution, that's just dragging half the C language into mine.
Besides, the C macros will still expand into C expressions, statements
and types; so not just half the language, but half the C source too.
Don't forget we're trying to translate the C, not find ways of avoiding
that task!
Macros in C can be used well to write clearer code, and that should be >>> fine to translate to your language (we are talking manual translation, >>> not automatic transcompilation - if you were doing that, you'd do it
from the C after pre-processing).
That doesn't work. For a start it will flatten all enumerations and
defines into literals; you need to preserve those.
"doesn't work" depends on your goal. If goal is to get running
executable as output from your compiler (IIUC "automatic
transcompilation" and the following text up to closing
parenthesis covers this case), then I see no problem
that expansion would cause.
I think DB meant being able to manually translate line by line. That can
work for small examples, but it doesn't really scale.
I anyway already have a tool that will do that. If this is the original
C of one example:
https://github.com/sal55/langs/blob/master/nano.c
Then my tool (a development of my C compiler) produces this file in my syntax:
https://github.com/sal55/langs/blob/master/nano.m
It looks great! But it won't compile; this is purely to help visualising
C code.
I have tried a few times to use this as a starting point to manually translate C programs to M, but there's always something that needs
fixing every few lines; it's usually a huge amount of work. And many
things can't be detected: they will produce legal M that is an incorrect representation of the C.
So in a line like this:
out^ := njClip(x7+x1>>14+128)
the operator priorities are all different.
Plus macros are expanded into literals and so on. You can do more work
on the tool to reduce the manual fixups needed, but generally this
solution is not viable.
But, we're not really seriously trying to translate a specific C program.
David Brown's point was to show that my language is really no different
from C. But the language /it implements/ doesn't claim to be, and there wouldn't be any great difficult in rewriting any C program in my
language, so long as your didn't try and do it token-by-token.
It would be the same task as translating a C program to D or Java or C#
or Zig or Rust. I think most agree those are different from C.
My language also has many differences in how such a lower-level language
is presented, like the module system for example. Or defaulting to
64-bit integers (causing subtle differences of behaviour). Or
out-of-order definitions. Or being expression-based no statement-based.
Or a dozen other matters I've already listed.
David Brown's point was to show that my language is really no different
from C. But the language /it implements/ doesn't claim to be, and there wouldn't be any great difficult in rewriting any C program in my
language, so long as your didn't try and do it token-by-token.
It would be the same task as translating a C program to D or Java or C#
or Zig or Rust. I think most agree those are different from C.
Bart <bc@freeuk.com> wrote:
Other languages may use command parameters, @ files, makefiles, or
untidy collections of 'import <module>` at the top of every module, that
need constant maintenance.
Hmm, if module A used function f from module B and I want to change
A to use f from C, then I need to change import statement.
I does
not matter if import statement is in A or in central file. OTOH
if imports stay stable then 'import' line does not change so no
need for exta maintenance.
OTOH in langage I use imports are
scoped. Routine rB in A can import B and use f from B, routine
rC in A can import C and use f from C. I do not think it would
work with your import table.
And I can compile each module
separately.
In fact, this is usual developement mode: I stop
the program, modify the module, compile, load and restart the
program. The point is that all program data and debugging setup
is preserved.
Anyway, I have benefit from independent compilation
and import lines are not a problem.
And, if you ask, I have makefile and it contains list of all
modules, so when I add a new module I must add it to the
makefile. I principle list of modules could be generated
automatically ("take all modules in files in current directory"),
but I prefer current way.
Some langages with modules have
"transitive closure" feature: when you give module to compiler
(or maybe extra tool) it will recompile all modules it needs.
But you still need list of "entry modules", that is modules
that should be compiled and are usable when user explicitely
request them by name, but otherwise would be unused.
Oops, I got distracted and did not finish this part. I mean,
in well written C program there will be implicit module structure, essentially ".c file = module".
Exported functions will be
declared in header files. One school says that there should be
.h file for each C file, this .h file containg "module" export info.
Less rigorous school allows single .h file (or some small number)
decaring exported function. Even if program slightly deviates
from such patterns usually this is not much work to separate
declarations of exported functions and move them in .h files
corresponding to .c files. I believe that gcc with appropriate
options would tell you if there is any function which gets
exported (is non-static) but which lacks declaration in
header file, so you can correct program to make sure that
everthing which needs to be exported is declared in header files
and rest is static. After that the C structure will map
1 to 1 to any resonable module system.
David Brown may explain more what he meant. But I think that my
view is similar to his: there is almost nothing new in your
language. You are moving in circle of ideas that were mainstream
in sixties,
mostly resolved in seventies and consider old hat now.
And for starter, it looks that all contenders
offer modules, with better features than yours.
On 07/12/2022 19:58, Bart wrote:
David Brown's point was to show that my language is really no
different from C. But the language /it implements/ doesn't claim to
be, and there wouldn't be any great difficult in rewriting any C
program in my language, so long as your didn't try and do it
token-by-token.
It would be the same task as translating a C program to D or Java or
C# or Zig or Rust. I think most agree those are different from C.
My point was that your language (the low-level compiled one) and C are similar styles - they are at a similar level, and are both procedural imperative structured languages. They have functions, variables, and pointers. They do not have higher order functions, objects,
overloading, generics/templates, events, actors, coroutines, RAII, metaprogramming, type inference, native multi-precision arithmetic,
parallel blocks, closures, sandboxing. They are not domain-specific, or tied to particular applications or environment.
higher order functions, objects,
overloading, generics/templates, events, actors, coroutines, RAII, metaprogramming, type inference, native multi-precision arithmetic,
parallel blocks, closures, sandboxing.
On 08/12/2022 09:08, David Brown wrote:
On 07/12/2022 19:58, Bart wrote:
David Brown's point was to show that my language is really no
different from C. But the language /it implements/ doesn't claim to
be, and there wouldn't be any great difficult in rewriting any C
program in my language, so long as your didn't try and do it
token-by-token.
It would be the same task as translating a C program to D or Java or
C# or Zig or Rust. I think most agree those are different from C.
My point was that your language (the low-level compiled one) and C are
similar styles - they are at a similar level, and are both procedural
imperative structured languages. They have functions, variables, and
pointers. They do not have higher order functions, objects,
overloading, generics/templates, events, actors, coroutines, RAII,
metaprogramming, type inference, native multi-precision arithmetic,
parallel blocks, closures, sandboxing. They are not domain-specific,
or tied to particular applications or environment.
I don't know what half of those mean.
My system language was upgraded for a while with higher level data types
(you seem to have skipped a level or two in your list), but then I
decided to keep it lower level.
I think languages should know their place, so let it do what it does as
well as it can, rather pretend to be something it's not. (And mine
mainly exists to implement the next language along.)
I anyway favour features that everyone can understand and appreciate.
Here's an example using a minor extension to my C compiler:
void print_this_module(void) {
puts(strinclude(__FILE__));
}
Put this in any module (or in more than one, or make it a macro), and
when called it will print the sourcecode of the module, which is
embedded within the executable. There are a dozen uses other than the
novelty one above.
higher order functions, objects,
overloading, generics/templates, events, actors, coroutines, RAII, metaprogramming, type inference, native multi-precision arithmetic, parallel blocks, closures, sandboxing.
Those are the sorts of features that are implemended more diversely
across different languages than simple ones. They will be harder to
translate from one language to another. I favour more conservative and
more universal features.
A language needs to be able to get things done, and the number one thing missing from mine is the ability to /effortlessly/ use third party
libraries. Not actors, whatever those are.
On 09/12/2022 01:52, Bart wrote:
Here's an example using a minor extension to my C compiler:
void print_this_module(void) {
puts(strinclude(__FILE__));
}
Put this in any module (or in more than one, or make it a macro), and
when called it will print the sourcecode of the module, which is
embedded within the executable. There are a dozen uses other than the
novelty one above.
And your basis for thinking /everyone/ understands this is ... what? I guess it looks clear enough for simple cases, but what about more
complicated circumstances? What if the code is not contained in a file,
but part of an on-the-fly compilation, or with source code from a pipe?
What if the file is a temporary one generated by transcompilation from
a higher level languages? Does it work properly with respect to the
#line pre-processor directive? How does it work regarding other
#include's in the file? How are macros and other pre-processing handled
in the file? What about someone trying to include an "infinite" file
like "/dev/random"? What about a file that contained characters that
are not acceptable by the compiler?
There are /lots/ of questions.
I think it is fair to say that a number of programmers would appreciate
a way to include data files embedded in their programs. Mostly you want
the files to be treated as data (initialising an array), rather than
strings, but sometimes strings are useful too.
(Like most people, I
solved this long ago for my own needs with a simple data-to-include-file utility). Including a files own source code is not likely to be needed
by many, but other files are more important.
Just for comparison, have a look at how the real C language has dealt
with this, as a similar (but more powerful and useful) feature has been
added to C23. Since C is not a one-man toy, discussions and proposals
are needed, involving proponents of the idea, C standards committee
members, users, compiler writers, and testers. It takes many rounds to establish what "everyone" understands, and what "everyone" appreciates -
as well as avoiding potential problems, security issues and other complications that are not obvious to most people.
<https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2898.htm> <https://thephd.dev/finally-embed-in-c23>
On 09/12/2022 11:54, David Brown wrote:
My scripting language uses `strinclude` for both. The program below
writes a C file then compiles it, supplying its own C compiler!
const compiler = strinclude("c:/m/bcc.exe")
<https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2898.htm>
<https://thephd.dev/finally-embed-in-c23>
On 09/12/2022 01:52, Bart wrote:
higher order functions, objects,
overloading, generics/templates, events, actors, coroutines, RAII,
metaprogramming, type inference, native multi-precision arithmetic,
parallel blocks, closures, sandboxing.
Those are the sorts of features that are implemended more diversely
across different languages than simple ones. They will be harder to
translate from one language to another. I favour more conservative and
more universal features.
Again, you favour things that seem more conservative and universal to
/you/.
But people with different programming backgrounds and habits could have completely different ideas of what is "conservative and universal". For many languages, type inference and generics is so integral that it would
seem very strange to declare variables of a given type - they may not
even see variables as a meaningful concept.
Of course you put things in your language that /you/ find appropriate -
you made it for yourself, and if some Prolog user or Sketch expert wants
to use it, they'll have to learn how it works. All I am asking you to
do is understand that your ideas, your preferences, your choices are
formed from your experiences and background - they are not "universal"
and do not necessarily apply to others.
On 09/12/2022 11:54, David Brown wrote:
On 09/12/2022 01:52, Bart wrote:
(Replying about 'strinclude' only)
Here's an example using a minor extension to my C compiler:
void print_this_module(void) {
puts(strinclude(__FILE__));
}
Put this in any module (or in more than one, or make it a macro), and
when called it will print the sourcecode of the module, which is
embedded within the executable. There are a dozen uses other than the
novelty one above.
And your basis for thinking /everyone/ understands this is ... what?
I guess it looks clear enough for simple cases, but what about more
complicated circumstances? What if the code is not contained in a
file, but part of an on-the-fly compilation, or with source code from
a pipe? What if the file is a temporary one generated by
transcompilation from a higher level languages? Does it work properly
with respect to the #line pre-processor directive? How does it work
regarding other #include's in the file? How are macros and other
pre-processing handled in the file? What about someone trying to
include an "infinite" file like "/dev/random"? What about a file that
contained characters that are not acceptable by the compiler?
There are /lots/ of questions.
You can say the same about #include in C. The search algorithm for
include files is actually complex, and is not set by the language: it is implementation defined.
My strinclude is simpler. The concept itself is simple: incorporate a
TEXT file as a string literal rather than C code, a task that many will
have wanted to do at some point.
This was a quick proof of concept for C. The search for non-absolute file-specs is relative to the current directory. In the original in my language, it is relative to the location of the lead module (to allow a program to be built remotely from anywhere in the file system).
For C I won't bother upgrading it.
Of course, people can enter all sorts of things as the file path which
are likely to cause problems. Just like they can for #include. And just
like they can, with languages that have compile-time evaluation and the ability to duplicate strings, when they write "A"*1000000000.
1GB is small enough to actually work, big enough to cause all sorts of problems, like a 1GB executable.
I think it is fair to say that a number of programmers would
appreciate a way to include data files embedded in their programs.
Mostly you want the files to be treated as data (initialising an
array), rather than strings, but sometimes strings are useful too.
My systems language has `bininclude` for binary files, but it's a poor implementation (a 1MB file will generate 1M AST nodes, one for each
byte, some 64MB in all, but `strinclude` for a 1MB file needs only a 1MB string).
My scripting language uses `strinclude` for both. The program below
writes a C file then compiles it, supplying its own C compiler!
const compiler = strinclude("c:/m/bcc.exe")
if not checkfile("newcc.exe") then
writestrfile("newcc.exe",compiler)
fi
writetextfile("test.c",
("#include <stdio.h>",
"int main(void) { puts(""Hi There " +strtime(getsystime())+ """);}"
))
execwait("newcc -run test.c")
(str-file = one big string; text-file = list of strings, one per line)
(Like most people, I solved this long ago for my own needs with a
simple data-to-include-file utility). Including a files own source
code is not likely to be needed by many, but other files are more
important.
Here's a simpler use:
when help_sw then
println strinclude("mm_help.txt")
It is invaluable in producing my one-file self-contained tools.
Just for comparison, have a look at how the real C language has dealt
with this, as a similar (but more powerful and useful) feature has
been added to C23. Since C is not a one-man toy, discussions and
proposals are needed, involving proponents of the idea, C standards
committee members, users, compiler writers, and testers. It takes
many rounds to establish what "everyone" understands, and what
"everyone" appreciates - as well as avoiding potential problems,
security issues and other complications that are not obvious to most
people.
<https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2898.htm>
<https://thephd.dev/finally-embed-in-c23>
Yeah, it's complicated when the language is already complicated and everything is done by committee /and/ you have billions of lines of
existing code to support and you have 100s of implementations.
That's an advantage of creating a small product with a limited user-base.
This sort of feature needs to be as simple as I've shown above.
BTW in C, I implemented strinclude in 20 lines like this:
function readstrinclude:unit p=
ichar text
lex()
checksymbol(lbracksym)
lex()
p := readexpression()
checksymbol(rbracksym)
lex()
if p.tag<>j_const or p.mode<>trefchar then
serror("String const expected")
fi
text := readfile(p.svalue)
if not text then
serror_s("Can't read strinclude file: #",p.svalue)
fi
return createstringconstunit(text,rfsize)
end
On 08/12/2022 00:30, antispam@math.uni.wroc.pl wrote:
Bart <bc@freeuk.com> wrote:
Other languages may use command parameters, @ files, makefiles, or
untidy collections of 'import <module>` at the top of every module, that >> need constant maintenance.
Hmm, if module A used function f from module B and I want to change
A to use f from C, then I need to change import statement.
If it happens that A imports both B and C, each of which export function
F, then you would need to write B.F() or C.F() from A anyway, to disambiguate.
I does
not matter if import statement is in A or in central file. OTOH
if imports stay stable then 'import' line does not change so no
need for exta maintenance.
Since I started using my 2022 module scheme, I very rarely have to look
at the module list. Mainly it's changed in order to create a different configuration of a program.
Actually it has dramatically simplified that kind of maintenance.
My scheme also allows circular and mutual imports with no restrictions.
I would link to some docs but I can sense you're not going to be
receptive. That's fine; you're used to your way of doing things.
OTOH in langage I use imports are
scoped. Routine rB in A can import B and use f from B, routine
rC in A can import C and use f from C. I do not think it would
work with your import table.
You mean a function privately imports a module? That sounds crazy - and chaotic. Suppose 100 different functions all import different subsets of
20 different modules (is that Python by any chance?)
There needs to be some structure, some organisation.
And I can compile each module
separately.
I can compile each program separately. Granularity moves from module to program. That's better. Otherwise why not compile individual functions?
In fact, this is usual developement mode: I stop
the program, modify the module, compile, load and restart the
program. The point is that all program data and debugging setup
is preserved.
You mean change one module of a running program? OK, that's not that
really a feature of a language I think, more of external tools,
especially IDEs and debuggers.
I would have no idea how to do that in C. But I used to do it at the application level where most functionality was implemented via
hot-loaded scripting modules. Then development was done from /within/
the running application.
Anyway, I have benefit from independent compilation
and import lines are not a problem.
I used to use independent compilation myself. I moved on to
whole-program compilation because it was better. But all the issues
involved with interfacing at the boundaries between modules don't
completely disappear, they move to the boundaries between programs
instead; that is, between libraries.
And, if you ask, I have makefile and it contains list of all
modules, so when I add a new module I must add it to the
makefile. I principle list of modules could be generated
automatically ("take all modules in files in current directory"),
but I prefer current way.
Well, my language doesn't use or need makefiles. While I got rid of
linkers as being a waste of time, I never got into makefiles at all.
There are however project files used by my mini-IDE, which contains additional info needed for listing, browsing, and editing the source
files, and for running the programs with test inputs.
But if /you/ wanted to build one of my projects from source, I would
need to provide exactly two files:
mm.exe the compiler
app.ma the source code
The latter being an automatically created amalgamation (produced with
`mm -ma app`). Build using `mm app`.
If you were on Linux or didn't want to use my compiler, then it's even simpler; I would provide exactly one file:
app.c Generated C source code (via `mc -c app`)
Here, you need a C compiler only. On Windows, you can build it using
`gcc app.c -oapp.exe`. Linux needs more options, listed at the top of
the file.
I haven't yet figured out a way of providing zero files if you wanted to build my apps from source.
But I guess none of this cuts any ice. After all, there are innumerable
ways of taking the most fantastically complex build process, and
wrapping up in one command or one file (docker etc).
The difference is that what I provide is genuinely simple: one bare
compiler, one actual source file.
Some langages with modules have
"transitive closure" feature: when you give module to compiler
(or maybe extra tool) it will recompile all modules it needs.
But you still need list of "entry modules", that is modules
that should be compiled and are usable when user explicitely
request them by name, but otherwise would be unused.
My stuff is simpler, believe me. When you have 1Mlps compilation speed,
most of this build stuff can go out the window.
Oops, I got distracted and did not finish this part. I mean,
in well written C program there will be implicit module structure, essentially ".c file = module".
I've seen lots of C source, it's rarely that tidy.
If it was, I'd be be able to use an unusual feature of my C compiler
where it can automatically discover the necessary modules by tracking
the header files (`bcc -auto main.c`).
Exported functions will be
declared in header files. One school says that there should be
.h file for each C file, this .h file containg "module" export info.
Less rigorous school allows single .h file (or some small number)
decaring exported function. Even if program slightly deviates
from such patterns usually this is not much work to separate
declarations of exported functions and move them in .h files
corresponding to .c files. I believe that gcc with appropriate
options would tell you if there is any function which gets
exported (is non-static) but which lacks declaration in
header file, so you can correct program to make sure that
everthing which needs to be exported is declared in header files
and rest is static. After that the C structure will map
1 to 1 to any resonable module system.
C is just so primitive when it comes to this stuff. I'm sure it largely
works by luck.
David Brown may explain more what he meant. But I think that my
view is similar to his: there is almost nothing new in your
language. You are moving in circle of ideas that were mainstream
in sixties,
So what are the new circles of ideas? All that crap in Rust that makes
coding a nightmare, and makes building programs dead slow? All those new functional languages with esoteric type systems? 6GB IDEs (that used to
take a minute and a half to load on my old PC)? No thanks.
I keep the languages I maintain accessible, and the ideas simple.
Any genuinely good ideas I would already have stolen if I liked them and
they were practical to implement.
But the trend now is to make even features like modules as complicated
and comprehensive as possible. (For example, there may not be 1:1 correspondence between file and module: multiple modules per file;
nested modules; modules split across multiple files. I keep it simple.)
mostly resolved in seventies and consider old hat now.
I'm think you're not looking at the right features of a language. ThereDoes this count as brace-free?
are some characteristics popular in the 70s that I like and maintain:
* Clean, uncluttered brace-free syntax
* Case-insensitive
* 1-based
* Line-oriented (no semicolons)
* Print/read as statements
C is still tremendously popular for many reasons. But anyone wanting to
code today in such a language will be out of luck if prefered any or all
of these characteristics. This is why I find coding in my language such
a pleasure.
Then, if we are comparing the C language with mine, I offer:
* Out of order definitions
* One-time definitions (no headers, interfaces etc)
* Expression-based
* Program-wide rather than module-wide compilation unit
* Build direct to executable; no object files or linkers
* Blazing fast compilation speed, can run direct from source
* Module scheme with tidy 'one-time' declaration of each module
* Function reflection (access all functions within the program)
* 64-bit default data types (ie. 'int' is 64 bits, 123 is 64 bits)
* No build system needed
* Create and directly compile One-file amalgamations of projects
* String and file embedding you know about
* One-file self-contained implementations
I haven't listed the literally one hundred small enhancements that make
the coding experience even in a lower-level system language with
primitive types so comfortable.
Few are remarkable or unique, but it's putting it all together in one
tidy package that counts.
And for starter, it looks that all contenders
offer modules, with better features than yours.
Sure, you have C++, Zig, Rust, Java, C#, Dart, ....
All with very advanced and complicated features. They also have big implementations and take ages to build projects.
(When I need more advanced features, I switch to my scripting language.
Which also, by design, shares the same syntax and most of the same characteristics and features.)
I think, like David Brown, you just don't get it.
Try and think of what I do as creating delicious meals in my kitchen
from my own recipies. Nothing new here either. But both you and DB
probably work (figuratively) in the food industry or run chains of restaurants, or work in a food laboratory.
Or are used to buying ready-meals from supermarkets.
On 09/12/2022 11:54, David Brown wrote:
On 09/12/2022 01:52, Bart wrote:
higher order functions, objects,
overloading, generics/templates, events, actors, coroutines, RAII,
metaprogramming, type inference, native multi-precision arithmetic,
parallel blocks, closures, sandboxing.
Those are the sorts of features that are implemended more diversely
across different languages than simple ones. They will be harder to
translate from one language to another. I favour more conservative
and more universal features.
Again, you favour things that seem more conservative and universal to
/you/.
Well, they were universal and obvious 40+ years ago. Nearly two
generations on, everyone is into more advanced features (mostly likely
due to being foisted on them in university courses).
Then it may be necessary to look at what would be obvious and intuitive
to anyone, or can be described in everyday terms like shelves of books, numbered drawers and so on. (Except that soon not many will know what a
book looks like.)
But people with different programming backgrounds and habits could
have completely different ideas of what is "conservative and
universal". For many languages, type inference and generics is so
integral that it would seem very strange to declare variables of a
given type - they may not even see variables as a meaningful concept.
Give it another generation, someone will reintroduce the idea of mutable variables as a brilliant new concept.
However I think you're wrong: there are a set of basic features that,
for time being, most will understand or can easily guess, often used in pseudo-code.
If I look at Intel processor manuals for example, the behaviour of instructions is described in a pseudo-code language looks a lot like
Algol. It has IF statements, explicit FOR-loops and mutable variables.
So, how about that; my syntax which I claim to be simple and univeral,
is clear enough to be used as pseudo-code.
These are some characteristics and fundamentals that I like, that are in danger of becoming extinct; they already are in many languages:
* Case-insensitive
* 1-based counting (if there is even anything to count!)
* Mutable variables, even the concept of 'state'
* Explicit arrays, and explicit indexing of arrays
* Iteration over A to B using explicit loops
* While loops
* Goto
* Build-in read/print /statements/ (or just having any i/o at all)
* Ordinary functions, you know, the ones you just declare rather just
being some named lambda expression.
These include many constructs popular in pseudo-code. So what do the developers of advanced languages actually have against clear code?
I get the impression that many can't take a language seriously if it
uses a syntax that just anyone can understand.
Of course you put things in your language that /you/ find appropriate
- you made it for yourself, and if some Prolog user or Sketch expert
wants to use it, they'll have to learn how it works. All I am asking
you to do is understand that your ideas, your preferences, your
choices are formed from your experiences and background - they are not
"universal" and do not necessarily apply to others.
Again, I think they are: more obvious, more intuitive, simpler, suitable
for use as pseudo-code, and far easier to port to an arbitrary language.
At least, an arbitrary language that hasn't completely done away with
the basics.
Bart <bc@freeuk.com> wrote:
My scheme also allows circular and mutual imports with no restrictions.
You probably mean "with no artifical restrictions". There is
fundamental restriction that everything should resolve in finite
number of steps.
There needs to be some structure, some organisation.
Exactly, private import is tool for better organisation.
I can compile each program separately. Granularity moves from module to
program. That's better. Otherwise why not compile individual functions?
In the past there was support for compiling individual functions, and
I would not exclude possibility that it will come back. But ATM
I prefer to keep things simple, so this functionality was removed.
I used to use independent compilation myself. I moved on to
whole-program compilation because it was better. But all the issues
involved with interfacing at the boundaries between modules don't
completely disappear, they move to the boundaries between programs
instead; that is, between libraries.
I consider programs to be different from libraries. Program may
use several libraries, in degenerate case library may be just a
single module. Compiling whole program has clear troubles with
large programs.
The latter being an automatically created amalgamation (produced with
`mm -ma app`). Build using `mm app`.
I could provide a single file, shell archive containing build script
and sources, but important part of providing sources is that people
can read them, understand and modify.
GNU folks have nice definition
of source: "preffered form for making modifications". I would guess
that 'app.ma' is _not_ your preffered form for making modifications,
so it is not really true source.
And to build from "source" I need
source first. And I provide _true_ sources to my users.
If you were on Linux or didn't want to use my compiler, then it's even
simpler; I would provide exactly one file:
app.c Generated C source code (via `mc -c app`)
Here, you need a C compiler only. On Windows, you can build it using
`gcc app.c -oapp.exe`. Linux needs more options, listed at the top of
the file.
Sorry, generated file is _not_ a source. If I were to modify C file
The difference is that what I provide is genuinely simple: one bare
compiler, one actual source file.
Sorry, for me "one file" is not a problem, there is 'tar' (de facto
standard for distributing sorce code)
And there is possible quite large dependency, namley Windows.
It is [not?] clear how much of your code _usefully_ runs in now-Window environment.
C is just so primitive when it comes to this stuff. I'm sure it largely
works by luck.
C is at low level, that is clear.
Good programming
environment should help. C as language is not helpful, one
may have fully compliant and rather unhelpful compiler. But
real C compilers tends to be as helpful as they can within
limit a C language. While C still limits what they can do,
there is quite a lot of difference betwen current popular
compiler and bare-bones legal comiler. And there are extra
tools and here C support is hard to beat.
So what are the new circles of ideas? All that crap in Rust that makes
coding a nightmare, and makes building programs dead slow? All those new
functional languages with esoteric type systems? 6GB IDEs (that used to
take a minute and a half to load on my old PC)? No thanks.
Borrow checker in Rust looks like good idea. There is good chance
that _idea_ will be adopted by several languages in near feature.
Not so new ideas are:
- removing limitations, that is making sure language constructs
work as general as possible (that allows to get rid of many
special constructs from older languages)
- nominal, problem dependent types. That is types should reflect
problem domain. In particular, domains which need types like
'u32' are somewhat specific, in normal domains fundamental types
are different
- functions as values/parameters. In particular functions have
types, can be members of data structures
- "full rights" for user defined types. Which means whatever
syntax/special constructs works on built-in types should
also work for user defined types
- function overloading
- type reconstruction
- garbage collection
- exception handling
- classes/objects
* Clean, uncluttered brace-free syntaxDoes this count as brace-free?
for i in 1..10 repeat (print i; s := s + i)
* Case-insensitive
* 1-based
* Line-oriented (no semicolons)
* Print/read as statements
Lot of folks consider the above misfeatures/bugs.
Concerning
'line-oriented' and 'intuitive, can you guess which changes to
following statement in 'line-oriented' syntax are legal and preserve
meaning?
nm = x or nm = 'log or nm = 'exp or nm = '%power or
nm = 'nthRoot or
nm = 'cosh or nm = 'coth or nm = 'sinh or nm = 'tanh or
nm = 'sech or nm = 'csch or
nm = 'acosh or nm = 'acoth or nm = 'asinh or nm = 'atanh or
nm = 'asech or nm = 'acsch or
nm = 'Ei or nm = 'erf or nm = 'erfi or nm = 'li or
nm = 'Gamma or nm = 'digamma or nm = 'dilog or
nm = '%root_sum =>
"iterate"
As a hit let me say that '=' is comparison. And this is single
statement, small changes to whitespace will change parse and lead
to wrong code or syntax/type error. BTW: you need real newsreader
to see it, Google and likes will change it so it no longer works.
C is still tremendously popular for many reasons. But anyone wanting to
code today in such a language will be out of luck if prefered any or all
of these characteristics. This is why I find coding in my language such
a pleasure.
Then, if we are comparing the C language with mine, I offer:
* Out of order definitions
That is considerd misfeature in modern time.
In modern languages
definition may generate some code to be run and order in which
this code is run matters.
* One-time definitions (no headers, interfaces etc)
* Expression-based
C is mostly expression-based.
There are langages that go further
than C, for example:
a := (s = 1; for i in 1..10 repeat (s := s + i); s)
is legeal in language that I use, but can not be directly translated to C. However, from examples that you gave it looked that your language
is _less_ expression-based than C.
* Program-wide rather than module-wide compilation unit
AFACS C leave choice to the implementer. If your language _only_
supports whole-program compilation, then this whould be
negative feature.
* Build direct to executable; no object files or linkers
That really question of implementation. Building _only_
to executable is misfeature (what about case when I want
to use a few routines in your language, but the rest including
main program is in different language?).
* Blazing fast compilation speed, can run direct from source
Again, that is implementation (some language features may slow
down compilation, as you know C allow fast comilation).
* Module scheme with tidy 'one-time' declaration of each module
* Function reflection (access all functions within the program)
* 64-bit default data types (ie. 'int' is 64 bits, 123 is 64 bits)
* No build system needed
That really depends on needs of your program. Some are complex
and need build system, some are simple and in principle could
be compiled with "no" build system. I still use Makefiles for
simple programs for two reasons:
- typing 'make' is almost as easy as it can get
- I want to have record of compiler used/compiler options/
libraries
Or are used to buying ready-meals from supermarkets.
Meals are different thing than programming languages. If you want
to say that _you_ enjoy yor language(s), then I got this. My point
was that you are trying to present your _subjective_ preferences
as something universal.
is that my programs work. So I like featurs that help me to get
working program and dislike ones that cause troubles. IME, the
following cause troubles:
- case insensitivity
- dependence on poorly specified defauls
- out of order definitions
- infexible tools that for example insist on creating executable
without option on making linkable object file
Concerning 1-based indexing, IME in more cases it causes trouble
than helps, but usually this is minor issue.
I use a lot
line oriented syntax. I can say that it works, simple examples
are easy, but there are unintuitive situations and sometimes troubles.
For example cut and paste works better for traditional syntax.
If there are problems, then beginers may be confused. As one
guy put it: trouble with white space is that one can not see it.
In fact,
it seems that majority goes in quite different direction.
On 10/12/2022 18:23, Bart wrote:
If I look at Intel processor manuals for example, the behaviour of
instructions is described in a pseudo-code language looks a lot like
Algol. It has IF statements, explicit FOR-loops and mutable variables.
This is exactly what I said - you /think/ certain concepts are
"universal" or "fundamental" because of your background, and that
includes heavy use of assembly coding. von Neumann computer
architecture has turned out to be very successful, and imperative
procedural programming is a good fit for such systems at the low level.
Not all processors fit that model, however, and there are niche devices
that are very different. (Internally, even mainstream devices like x86 processors deviate substantially from strict von Neumann models.)
That does not mean, however, that such languages are ideal for
programming. Programming is the art of taking a task from the problem domain and ending up with something in the implementation domain. For
most processors, a C-like language (which includes your compiled
language - imperative and procedural) is close to the implementation domain. It is, however, typically very far from the problem domain. A high level language such as Python is going to be closer to the problem domain.
The closer your language choice is to the problem domain, the shorter
the program, the easier it is to see (or prove) that it is correct, and
the shorter development time.
Different kinds of task in the problem domain are best described in
different kinds of language. Different situations call for different selections of level of language and trade-offs. But common to all programming is this progression from the problem to the implemented
solution.
On 11/12/2022 19:46, David Brown wrote:
On 10/12/2022 18:23, Bart wrote:
If I look at Intel processor manuals for example, the behaviour of
instructions is described in a pseudo-code language looks a lot like
Algol. It has IF statements, explicit FOR-loops and mutable variables.
This is exactly what I said - you /think/ certain concepts are
"universal" or "fundamental" because of your background, and that
includes heavy use of assembly coding. von Neumann computer
architecture has turned out to be very successful, and imperative
procedural programming is a good fit for such systems at the low
level. Not all processors fit that model, however, and there are niche
devices that are very different. (Internally, even mainstream devices
like x86 processors deviate substantially from strict von Neumann
models.)
You're missing my point: the description of what the instructions did,
which we can assume to be detailed pseudo-code, used explicit loops for example, a feature missing or marginalised in FP.
I asked, why didn't they use recursion in their pseudo-code? Why didn't
my Wikepedia example do so rather than use 'while' loops?
I say it's because such features are understood by more people. You will disagree of course; because /you/ can understand FP code, so must everyone.
When I look at my paper tax return (or an IKEA instruction leaflet), it
will contain instructions like: 'go to section 7' or 'go to page 12'. So
you can assume that 'goto' at least is well understood!
That does not mean, however, that such languages are ideal for
programming. Programming is the art of taking a task from the problem
domain and ending up with something in the implementation domain. For
most processors, a C-like language (which includes your compiled
language - imperative and procedural) is close to the implementation
domain. It is, however, typically very far from the problem domain.
A high level language such as Python is going to be closer to the
problem domain.
Python? Probably my scripting language is closer to the problem domain
too. Mine however has 'goto'!
The closer your language choice is to the problem domain, the shorter
the program, the easier it is to see (or prove) that it is correct,
and the shorter development time.
That doesn't work with functional languages, not unless you're a genius
with a PhD in computer science. The program might be 10 times shorter
but 100 times more cryptic.
Different kinds of task in the problem domain are best described in
different kinds of language. Different situations call for different
selections of level of language and trade-offs. But common to all
programming is this progression from the problem to the implemented
solution.
Why do think I decided to create a scripting language at all? I first
did so in late 80s, the next step up to the non-programmable command
language of my application. It was meant also for users of my app, who
needed to do domain-specific scripting relevant to the application.
It was higher level than the one used to implemented the application. It
was domain-specific in having built-in types such as 3D points/vertices
and 3D transformation matrices.
So if P, Q were the endpoints of a line, then (P+Q)/2 was the midpoint,
while A*B might combine two transformation matrices into one. No memory addresses in sight.
Maybe I know something about the need for a more accessible language.
However one big part of that language was creating and working with GUI elements (dialogs etc), which was still a slog even in scripting code.
How much help would Haskell have been there?
On 12/12/2022 03:17, Bart wrote:
When I look at my paper tax return (or an IKEA instruction leaflet),
it will contain instructions like: 'go to section 7' or 'go to page
12'. So you can assume that 'goto' at least is well understood!
Different algorithms are clear when expressed in different ways.
You want the greatest common denominator of two numbers, a and b ? If a
and b are the same, that's the GCD. If b is bigger than a, swap them.
Then find the GCD of b and (a - b).
Oh look, it turns out recursion is "universally understood".
You want to go shopping? Make a list. Get the first thing on the list, then get the rest of the list. Stop when the list is empty. So list processing, pattern matching and recursion is universal - there are no variables, loops or gotos in that description.
You need to get some things in one shop, other things in a different
shop? Take all the things from the first list that you can get in the
first shop, and put that on a new list. Now you have the key functional programming "filter" function as universal, even if the terminology of functional programming is unfamiliar.
You realise you need to bake two cakes instead of one? Double
everything on the list. Now "map" is universal.
You have recipes for six different kinds of cake. To make double-sized cakes, you need to double the ingredients and add 30% to the cooking
time. Now you have a higher-order function.
You have a things-to-do list? Do the first one, then move on to the
rest of the list. That's recursion and lazy evaluation.
Imagine the list of all prime numbers. Take the first 5 containing the digit "3". It seems that understanding how to manipulate infinite lists
is easy too.
That just about covers the key functional programming concepts - and
you've barely left the kitchen.
You realise you need to bake two cakes instead of one? Double
everything on the list. Now "map" is universal.
You want to go shopping? Make a list. Get the first thing on the list, then get the rest of the list. Stop when the list is empty.
You have a things-to-do list? Do the first one, then move on to the
rest of the list. That's recursion and lazy evaluation.
On 12/12/2022 11:56, David Brown wrote:
On 12/12/2022 03:17, Bart wrote:
When I look at my paper tax return (or an IKEA instruction leaflet),
it will contain instructions like: 'go to section 7' or 'go to page
12'. So you can assume that 'goto' at least is well understood!
Different algorithms are clear when expressed in different ways.
You want the greatest common denominator of two numbers, a and b ? If
a and b are the same, that's the GCD. If b is bigger than a, swap
them. Then find the GCD of b and (a - b).
Oh look, it turns out recursion is "universally understood".
You want to go shopping? Make a list. Get the first thing on the
list, then get the rest of the list. Stop when the list is empty. So
list processing, pattern matching and recursion is universal - there
are no variables, loops or gotos in that description.
You need to get some things in one shop, other things in a different
shop? Take all the things from the first list that you can get in the
first shop, and put that on a new list. Now you have the key
functional programming "filter" function as universal, even if the
terminology of functional programming is unfamiliar.
You realise you need to bake two cakes instead of one? Double
everything on the list. Now "map" is universal.
You have recipes for six different kinds of cake. To make
double-sized cakes, you need to double the ingredients and add 30% to
the cooking time. Now you have a higher-order function.
You have a things-to-do list? Do the first one, then move on to the
rest of the list. That's recursion and lazy evaluation.
Imagine the list of all prime numbers. Take the first 5 containing
the digit "3". It seems that understanding how to manipulate infinite
lists is easy too.
That just about covers the key functional programming concepts - and
you've barely left the kitchen.
A nice set of examples, except for the higher order function one, which
I don't get.
Here are some observations:
* Imperative languages have recursion too.
* Things like map and reduce can be expressed in imperative code too,
via built-in functions, or ones that you can write yourself ...
* ... which leads to the fact that imperative offers the choice to
express the tasks using lower level features, offering more flexibility
* My beef with recursion as used in FP is using it for everything, when iterative would be clearer
* Those tasks would typically be expressed much more tersely in FP,
which also has a penchant for stringing sequences of them together on
one complex line (but this seems popular everywhere now). In imperative, deeply nested function calls would be an anti-pattern.
* You mentioned a shopping list; I quite like code to /look/ like a
shopping list. I don't mind reading 10 or 20 lines of clear code where I
can follow every step; it's better than reading one long line that I
can't grok. Where would I even stick a debug print if I wanted to know
an intermediate value.
You realise you need to bake two cakes instead of one? Double
everything on the list. Now "map" is universal.
As is mutable data. Or do you mean create a new list?
What exactly do
you double anyway? A typical ingredients list looks like this:
["eggs":1, "sugar":40, "SR flour":40]
Doubling is not that obvious (and the number for eggs has to be whole;
other units are grams).
You want to go shopping? Make a list. Get the first thing on the list, then get the rest of the list. Stop when the list is empty.
What does that actually look like in Haskell? I can tell you that
shopping as it's done in real-life is not done recursively.
In imperative it's:
proc do_shopping(list) =
for item in list do
buy(item)
end
end
Or one-liners:
for item in list do buy(item) end
apply(buy, list) # not map as there is no result
In imperative-recursive, if you have to, is:
proc do_shopping(list) =
if list then
buy(head(list))
do_shopping(tail(list)
fi
end
(I agree parametic pattern-matching to get the two parts of the list
would be better. But imperative is simpler here anyway.)
You have a things-to-do list? Do the first one, then move on to the
rest of the list. That's recursion and lazy evaluation.
But the to-do-list already exists? If there 1M things to do, the list
will have 1M items? That's not a great example of lazy evaluation (the
primes is better).
You might as well say that imperative code is lazily evaluated, as it consists of a sequence of steps done one at a time, while, ironically,
FP code isn't as it is one big expression.
OK, I don't have a particular issue with FP features in small amounts.
As I said and showed, they can come up in imperative code two.
I have two broad objections:
* All the FP features I don't understand and don't find intuitive,
mainly do with functions (higher order, closures, currying etc).
Pattern-matching, map, reduce etc I can deal with; the concepts are
easy, and they can trivially expressed in non-FP terms.
* Basing an entirely language around FP features.
On 12/12/2022 11:56, David Brown wrote:
I have two broad objections:
* All the FP features I don't understand and don't find intuitive,
mainly do with functions (higher order, closures, currying etc).
Pattern-matching, map, reduce etc I can deal with; the concepts are
easy, and they can trivially expressed in non-FP terms.
* Basing an entirely language around FP features.
On 12/12/2022 14:36, Bart wrote:
On 12/12/2022 11:56, David Brown wrote:
I have two broad objections:
* All the FP features I don't understand and don't find intuitive,
mainly do with functions (higher order, closures, currying etc).
Pattern-matching, map, reduce etc I can deal with; the concepts are
easy, and they can trivially expressed in non-FP terms.
* Basing an entirely language around FP features.
I've been looking at examples on rosettacode.org. Most languages there
are conventional (my style) other than all the weird ones plus FP.
But one task caught my eye:
https://rosettacode.org/wiki/Determine_if_a_string_has_all_unique_characters#Haskell
as all three Haskell versions seem to make meal of it. I had been
looking for a short cryptic Haskell example; this was a long cryptic one!
One mystery is how it gets the output (of first version) properly lined
up, as I can't see anything relevant in the code.
Half my version below is all the fiddly formatting; this is where I'd consider this a weak spot in my language and think about what could
improve it.
Other languages (eg. OCaml) keep the output minimal.
On 07/12/2022 19:58, Bart wrote:
My point was that your language (the low-level compiled one) and C are similar styles - they are at a similar level, and are both procedural imperative structured languages.
(None of this suggests you "copied" C. You simply have a roughly
similar approach to solving the same kinds of tasks - you probably had experience with much the same programming languages as the C designers,
and similar assembly programming experience before making your languages
at the beginning.)
Note: C makes little use of true array pointers; it likes to use T*types not (T*)[], which mean my example would be written as A[i] anyway.
Programming in Eiffel, Haskell, APL, Forth or Occam is /completely/
different - you approach your coding in an entirely different way, and
it makes no sense to think about translating from one of these to C (or
to each other).
On 11/12/2022 16:50, antispam@math.uni.wroc.pl wrote:
Bart <bc@freeuk.com> wrote:
(I don't think you've made it clear whether the other language(s) you've refered to are some mainstream ones, or one(s) that you have devised. I
will assume the latter and tone down my remarks. A little.)
My scheme also allows circular and mutual imports with no restrictions.
You probably mean "with no artifical restrictions". There is
fundamental restriction that everything should resolve in finite
number of steps.
Huh? That doesn't come up. Anything which is recursively defined (eg.
const a=b, b=a) is detected, but that is due to out-of-order not
circular modules.
There needs to be some structure, some organisation.
Exactly, private import is tool for better organisation.
Sorry, all I can see is extra work; it was already a hassle having to
write `import B` on top of every module that used B, when it was visible
to all functions, because of having to manage that list of imports /per module/. Now I have to do that micro-managing /per function/?
(Presumably this language has block scopes: can this import also be
private to a nested block within each function?)
With module-wide imports, it is easy to draw a diagram of interdependent modules; with function-wide imports, that is not so easy, which is why I think there will be less structure.
I can compile each program separately. Granularity moves from module to
program. That's better. Otherwise why not compile individual functions?
In the past there was support for compiling individual functions, and
I would not exclude possibility that it will come back. But ATM
I prefer to keep things simple, so this functionality was removed.
With whole program compilation, especially used in the context of a
resident tool that incorporates a compiler, with resident symbol tables, resident source and running code in-memory (actually, just like my very
first compilers), lots of possibiliies open up, of which I've hardly scratched the surface.
Including compiling/recompiling a function at a time.
Although part-recompiling during a pause in a running program, then
resuming, would still be very tricky. That would need debugging
features, and I would consider, in that case, running via an interpreter.
My point: a system that does all this would need all the relevant bits
in memory, and may involve all sorts of complex components.
But a
whole-program compiler that runs apps in-memmory already does half the work.
I used to use independent compilation myself. I moved on to
whole-program compilation because it was better. But all the issues
involved with interfacing at the boundaries between modules don't
completely disappear, they move to the boundaries between programs
instead; that is, between libraries.
I consider programs to be different from libraries. Program may
use several libraries, in degenerate case library may be just a
single module. Compiling whole program has clear troubles with
large programs.
My definition of 'program', on Windows, is a single EXE or DLL file.
I expect larger applications to consist of a collection of EXE and DLL
files. My own will have one EXE and zero or more DLLs, but I would also
make extensive use of scripting modules, that have different rules.
The latter being an automatically created amalgamation (produced with
`mm -ma app`). Build using `mm app`.
I could provide a single file, shell archive containing build script
and sources, but important part of providing sources is that people
can read them, understand and modify.
I don't agree. On Linux you do it with sources because it doesn't have a reliable binary format like Windows that will work on any machine. If
there are binaries, they might be limited to a particular Linux
distribution.
(Binaries on Linux have always been a mystery to me, starting with the
fact that they don't have a convenient extension like .exe to even tell
what it is.)
GNU folks have nice definition
of source: "preffered form for making modifications". I would guess
that 'app.ma' is _not_ your preffered form for making modifications,
so it is not really true source.
No, but deriving the true sources from app.ma is trivial, since it is basically a concatenation of the relevant files.
And to build from "source" I need
source first. And I provide _true_ sources to my users.
If you were on Linux or didn't want to use my compiler, then it's even
simpler; I would provide exactly one file:
app.c Generated C source code (via `mc -c app`)
Here, you need a C compiler only. On Windows, you can build it using
`gcc app.c -oapp.exe`. Linux needs more options, listed at the top of
the file.
Sorry, generated file is _not_ a source. If I were to modify C file
This is not for modifying. 99% of the time I want to build an open
source C project, it is in order to provide a running binary, not spend
hours trying to get it to build. These are the obstacles I have faced:
* Struggling with formats like .gz2 that require multiple steps on Windows
* Ending up with myriad files scatterred across myriad nested directories
* Needing to run './configure' first (this will not work on Windows...)
* Finding a 'make' /program/ (my gcc has a program called
mingw32-make.exe; is that the one?)
* Getting 'make' to work. Usually it fails partway and makefiles can be
so complex that I have no way of figuring a way out
* Or, trying to compile manually, struggling with files which are all
over the place and imparting that info to a compiler.
I don't have any interest in this; I just want the binary!
So, with my own programs, if I can't provide a binary (eg. they are not trusted), then one step back from a single binary file, is a single amalgamated source file.
I first did this in 2014, as a reaction to the difficulties I kept
facing: I wanted any of my applications to be as easy to build as hello.c.
If someone wants the original, discrete sources, then sure they can have
a ZIP file, which generally will have files that unpack into a single directly. But it's on request.
The difference is that what I provide is genuinely simple: one bare
compiler, one actual source file.
Sorry, for me "one file" is not a problem, there is 'tar' (de facto standard for distributing sorce code)
Yeah, I explained how well that works above. So the last Rust
implementation was a single binary download (great!), but it installed
itself as 56,000 discrete fies and across don't know how many 1000s of directories (not so great). And it didn't work (it requires additional tools).
Being able to ZIP or TAR a sprawling set of files into giant binary
makes it marginally easier to transmit or download, but it doesn't
really address complexity.
And there is possible quite large dependency, namley Windows.
Yeah, my binaries run on Windows. Aside from requiring x64 and using
Win64 ABI, they use one external library MSVCRT.DLL,
which itself uses
Windows.
For programs that run on Windows and Linux, those depend on libraries
used. For 'M' programs, one module has to be chosen from Windows and
Linux versions; To run on Linux, I have to do this:
mc -c -linux app.m # On Windows, makes app.c, using
# the Linux-specific module
gcc app.c -oapp -lm etc # On Linux
./app
but M makes little use of WinAPI. With my interpreter, the process is as follows:
c:\qx>mc -c -linux qq # On Windows
M6 Compiling qq.m---------- to qq.c
Copy qq.c to c:\c then under WSL:
root@DESKTOP-11:/mnt/c/c# gcc qq.c -oqq -fno-builtin -lm -ldl
Now I can run scripts under Linux:
root@DESKTOP-11:/mnt/c/c# ./qq -nosys hello
Hello, World!
However, notice the '-nosys' option; this is because qq automatically incorporates a library suite that include a GUI library based on Win32. Without that, it would complain of not finding user32.dll etc.
I would need to dig up an old set of libraries or create new
Linux-specific ones. A bit of extra work. But see how the entire app is contained within that qq.c file.
It is [not?] clear how much of your code _usefully_ runs in now-Window environment.
OK, let's try my C compiler. Here I've done 'mc -c -linux cc`, copied
cc.q, and compiled under WSL as bcc:
root@DESKTOP-11:/mnt/c/c# ./bcc -s hello.c
Compiling hello.c to hello.asm
root@DESKTOP-11:/mnt/c/c# ./bcc -e hello.c
Preprocessing hello.c to hello.i
root@DESKTOP-11:/mnt/c/c# ./bcc -c hello.c
Compiling hello.c to hello.obj
root@DESKTOP-11:/mnt/c/c# ./bcc -exe hello.c
Compiling hello.c to hello.exe
msvcrt
msvcrt.dll
SS code gen error: Can't load search lib
So, most things actually work; only creating EXE doesn't work, because
it needs access to msvcrt.dll. But even it it did, it would work as a cross-compiler, as its code generator is for Win64 ABI.
But I think this shows useful stuff can be done. A more interesting test (which used to work, but it's too much effort right now), is to get my M compiler working on Linux (the 'mc' version that targets C), and use
that to build qq, bcc etc from original sources on Linux.
In all, my Windows stuff generally works on Linux. Linux stuff generally doesn't work on Windows, in terms of building from source.
C is just so primitive when it comes to this stuff. I'm sure it largely
works by luck.
C is at low level, that is clear.
The way it does modules is crude. So was my scheme in the 1980s, but it
was still one step up from C. My 2022 scheme is miles above C now.
The
underlying language can still be low level, but you can at least fix
some aspects.
I think a better module scheme could be retrofitted to C, but I'm not
going to do it.
Good programming
environment should help. C as language is not helpful, one
may have fully compliant and rather unhelpful compiler. But
real C compilers tends to be as helpful as they can within
limit a C language. While C still limits what they can do,
there is quite a lot of difference betwen current popular
compiler and bare-bones legal comiler. And there are extra
tools and here C support is hard to beat.
I don't agree with spending 1000 times more effort in devising complex
tools compared with just fixing the language.
So what are the new circles of ideas? All that crap in Rust that makes
coding a nightmare, and makes building programs dead slow? All those new >> functional languages with esoteric type systems? 6GB IDEs (that used to
take a minute and a half to load on my old PC)? No thanks.
Borrow checker in Rust looks like good idea. There is good chance
that _idea_ will be adopted by several languages in near feature.
OK. I've heard that that makes coding in Rust harder. Also that makes compilation slower. Not very enticing features!
Not so new ideas are:
- removing limitations, that is making sure language constructs
work as general as possible (that allows to get rid of many
special constructs from older languages)
- nominal, problem dependent types. That is types should reflect
problem domain. In particular, domains which need types like
'u32' are somewhat specific, in normal domains fundamental types
are different
- functions as values/parameters. In particular functions have
types, can be members of data structures
- "full rights" for user defined types. Which means whatever
syntax/special constructs works on built-in types should
also work for user defined types
- function overloading
- type reconstruction
- garbage collection
- exception handling
- classes/objects
Are these what your language supports? (If you have your own.)
I can't say these have ever troubled me. My scripting language has
garbage collection, and experimental features for exceptions and playing
with OOP, and one or two taken from functional languages.
Being dynamic, it has generics built-in. But it deliberately keeps type systems at a simple, practical level (numbers, strings, lists, that sort
of thing), because the aim is for easy coding.
If you want hard, then
Rust, Ada, Haskell etc are that way -->!
* Clean, uncluttered brace-free syntaxDoes this count as brace-free?
for i in 1..10 repeat (print i; s := s + i)
Not if you just substitude brackets for braces. Brackets (ie "()") are
OK within one line, otherwise programs look too Lispy.
* Case-insensitive
* 1-based
* Line-oriented (no semicolons)
* Print/read as statements
Lot of folks consider the above misfeatures/bugs.
I know.
Concerning
'line-oriented' and 'intuitive, can you guess which changes to
following statement in 'line-oriented' syntax are legal and preserve meaning?
nm = x or nm = 'log or nm = 'exp or nm = '%power or
nm = 'nthRoot or
nm = 'cosh or nm = 'coth or nm = 'sinh or nm = 'tanh or
nm = 'sech or nm = 'csch or
nm = 'acosh or nm = 'acoth or nm = 'asinh or nm = 'atanh or
nm = 'asech or nm = 'acsch or
nm = 'Ei or nm = 'erf or nm = 'erfi or nm = 'li or
nm = 'Gamma or nm = 'digamma or nm = 'dilog or
nm = '%root_sum =>
"iterate"
As a hit let me say that '=' is comparison. And this is single
statement, small changes to whitespace will change parse and lead
to wrong code or syntax/type error. BTW: you need real newsreader
to see it, Google and likes will change it so it no longer works.
Thunderbird screws it up as well, unless it is meant to have a ragged
left edge. But not sure what your point is.
Non-line-oriented (like C, like JSON) is better for machine readable
code, that can also be transmitted with less risk of garbling. But when
when 90% of semicolons in C-style languages coincidence with
end-of-line, you need to start question the point of them.
Note that C's preprocessor is line-oriented, but C itself isn't.
C is still tremendously popular for many reasons. But anyone wanting to
code today in such a language will be out of luck if prefered any or all >> of these characteristics. This is why I find coding in my language such
a pleasure.
Then, if we are comparing the C language with mine, I offer:
* Out of order definitions
That is considerd misfeature in modern time.
Really? My experiments showed that modern languages (not C or C++) do
allow out-of-order functions. This gives great freedom in not worrying
about whether function F must go before G or after, or being able to
reorder or copy and paste.
In modern languages
definition may generate some code to be run and order in which
this code is run matters.
* One-time definitions (no headers, interfaces etc)
* Expression-based
C is mostly expression-based.
No, it's mostly statement-based. Although it might be that most
statements are expression statements (a=b; f(); ++c;).
You can't do 'return switch() {...}' for example, unless using gcc extensions.
There are langages that go further
than C, for example:
a := (s = 1; for i in 1..10 repeat (s := s + i); s)
is legeal in language that I use, but can not be directly translated to C. However, from examples that you gave it looked that your language
is _less_ expression-based than C.
I don't use the feature much. I had it from 80s, then switched to statement-based for a few years to match the scripting language, now
both are expression-based.
One reason it's not used more is because it causes problems when
targetting C. However I like it as a cool feature.
* Program-wide rather than module-wide compilation unit
AFACS C leave choice to the implementer. If your language _only_
supports whole-program compilation, then this whould be
negative feature.
* Build direct to executable; no object files or linkers
That really question of implementation. Building _only_
to executable is misfeature (what about case when I want
to use a few routines in your language, but the rest including
main program is in different language?).
There were escape routes involving OBJ files, but that's fallen into
disuse and needs fixing. For example, I can't so `mm -obj app` ATM, but
could do this, when I've cleared some bugs:
mm -asm app # app.m to app.asm
aa -obj app # app.asm to app.obj
gcc app.obj lib.o -oapp.exe # or lib.a?
This (or something near) allows static linking of 'lib' instead of
dynamic, or including lib written in another language.
Bart <bc@freeuk.com> wrote:
I don't agree. On Linux you do it with sources because it doesn't have a
reliable binary format like Windows that will work on any machine. If
there are binaries, they might be limited to a particular Linux
distribution.
You do not get it. I create binaries that work on 10 year old Linux
and new one. And on distributions that I never tried.
Of course,
I mean that binaries are for specific architecture, separate
for i386 Linux and x86_64 Linux (that covers PC-s, I would have to
provide more if I wanted to support more architectures).
Concerning binary format, there were two: Linux started with a.out
and switched to ELF in second half of nineties.
You also ignore educational aspect: some folks fetch sources to
learn how things are done.
Concerning not having extension: you can add one if you want,
moderatly popular choices are .exe or .elf.
Linux executable it should not matter if it is a shell script,
interpreted Python file or machine code. So exention should
not "give away" nature of executable.
And having no extension
means that users are spared needless typing
No, but deriving the true sources from app.ma is trivial, since it is
basically a concatenation of the relevant files.
Not less trivial than running 'tar' (which is standard component
on Linux).
* Needing to run './configure' first (this will not work on Windows...)
I saw one case then a guy tried to run './configure' on Windows NT
and Windows NT kept crashing.
It made a little progress and than
crashed, so that guy restarted it hoping that eventually it will
finish (after a week or two he gave up and used Linux). But
usually './configure' is not that bad. It make take a lot of
time, IME './configure' that run in seconds on Linux needed
several minutes on Windows.
And of course you need to install
essential dependencies, good program will tell you what you need
to install first, before running configure. But you need to
understand what they mean...
* Finding a 'make' /program/ (my gcc has a program called
mingw32-make.exe; is that the one?)
Probably. Normal advice for Windows folks is to install thing
called msys (IIUC it is msys2 now) which contains several tools
incuding 'make'. You are likely to get it as part of bigger
bundle, I am not up to date to tell you if this bundle will
be called 'gcc' or something else.
I don't have any interest in this; I just want the binary!
Well, I provide Linux binaries, but only sources for Windows
users. One reason is that I have only Linux on my personal
machine, so to deal with Windows I need to lease a machine.
Different reason is that I an not paid for programming, I do
this because I like to program and to some degree to build
community.
But if some potential members of community would
like to benefit but are unwilling to spent little effort.
Of course, in big community there may be a lot of "free
riders" who benefit without contributing anything whithout
bad effect because other folks will do needed work. But
here I am dealing with small community. I did port
to Windows to make sure that it actually works and there
are not serious problems. But I leave to other creation
of binaries and reporting possible build problems. If
nobody is willing to do this, then from my point of
view Windows has no users and is not worth supporting.
Being able to ZIP or TAR a sprawling set of files into giant binary
makes it marginally easier to transmit or download, but it doesn't
really address complexity.
In my book single blob of 20M is more problematic than 10000 files,
2kB each. At deeper level complexity is the same, but blob lacks
useful structure given by division into files and subdirectories.
So, most things actually work; only creating EXE doesn't work, because
it needs access to msvcrt.dll. But even it it did, it would work as a
cross-compiler, as its code generator is for Win64 ABI.
Yes. It was particularly funny whan you had compiler running on
Raspberry Pi, but producing Intel code...
But I think this shows useful stuff can be done. A more interesting test
(which used to work, but it's too much effort right now), is to get my M
compiler working on Linux (the 'mc' version that targets C), and use
that to build qq, bcc etc from original sources on Linux.
In all, my Windows stuff generally works on Linux. Linux stuff generally
doesn't work on Windows, in terms of building from source.
Our experience differ. There were times that I had to work on
Windows machine and problem was that Windows does not come with
tools that I consider essential.
The way it does modules is crude. So was my scheme in the 1980s, but it
was still one step up from C. My 2022 scheme is miles above C now.
Concering "miles above": using C one can create shared libraries.
Some shared libraries may be system provided, some may be private.
Within C ecosystem, one you have corresponding header files you
can use them as "modules". And they are usable with other languages.
AFAIK no other module system can match _this_.
I don't agree with spending 1000 times more effort in devising complex
tools compared with just fixing the language.
It is cheaper to have 1000 people doing tools, than 100000 people
fixing their programs.
On 17/12/2022 06:07, antispam@math.uni.wroc.pl wrote:
When /I/ provide sources (that is, a representation that is one step
back from binaries), to build on Linux, then it will build on Linux.
They will have a dependency on a C compiler that can produce a ELF file,
and I now stipulate either gcc or tcc.
On 17/12/2022 06:07, antispam@math.uni.wroc.pl wrote:
Bart <bc@freeuk.com> wrote:
Of course,
I mean that binaries are for specific architecture, separate
for i386 Linux and x86_64 Linux (that covers PC-s, I would have to
provide more if I wanted to support more architectures).
Concerning binary format, there were two: Linux started with a.out
and switched to ELF in second half of nineties.
(I don't understand that; a.out is a filename; ELF is a file format.)
Concerning not having extension: you can add one if you want,
moderatly popular choices are .exe or .elf.
But nobody does. Main problem is in forums like this: if I say
`hello.exe`, everyone knows that's a binary executable for Windows. But
if I mention `hello`, how are you supposed to tell that I'm talking
about a Linux executable?
I know that Linux doesn't care about extensions, but people do. After
all it still uses, by convention, extensions like .c -s .o .a .so, so
why not actual binaries by convention?
But for using normal
Linux executable it should not matter if it is a shell script,
interpreted Python file or machine code. So exention should
not "give away" nature of executable.
You can have a neutral extension that doesn't give it away either. Using
no extension is not useful: is every file with no extension something
you can execute?
But there are also ways to execute .c files directly, and of course .py
files which are run from source anyway.
It simply doesn't make sense. On Linux, I can see that executables are displayed on consoles in different colours; what happened when there was
no colour used?
And having no extension
means that users are spared needless typing
Funny you should bring that up, because every time you run a /C
compiler/ on a /C source file/, you have to type the extension like this:
gcc hello.c
which also writes the output as a.exe or a.out, so you further need to
write at least:
gcc hello.c -o hello # hello.exe on Windows
I would only write this:
bcc hello
and it works out, by some very advanced AI, that I want to compile
hello.c into hello.exe. And once you have hello.exe, you can run it like this:
hello
You don't need to type .exe. So, paradoxically, having extensions means having to type them less often:
mm -pcl prog # old compiler: translate prog.m to prog.pcl
pcl -asm prog # prog.pcl to prog.asm
aa prog # prog.asm to prog.exe
prog # run it
At no point did I need to write an extension. It is implied by the
program I invoked.
Could it be simply that file extensions are sometimes helpful, sometimes inconvenient or irrelevant, and mostly it all just works without much trouble?
On 17/12/2022 14:22, Bart wrote:
For data files, it can often be convenient to have an extension
indicating the type - and it is as common on Linux as it is on Windows
to have ".odt", ".mp3", etc., on data files.
People use extensions where they are useful, and skip them when they are counter-productive (such as for executable programs).
When you are writing code, and you have a function "twiddle" and an
integer variable "counter", you call them "twiddle" and "counter". You don't call them "twiddle_func" and "counter_int". But maybe sometimes
you find it useful - it's common to write "counter_t" for a type, and
maybe you'd write "xs" for an array rather than "x". Filenames can
follow the same principle - naming conventions can be helpful, but you
don't need to be obsessive about it or you end up with too much focus on
the wrong thing.
On *nix, every file with the executable flag can be executed - that's
what the flag is for.
Sometimes it is convenient to be able to see which files in a directory
are executables, directories, etc. That's why "ls" has flags for
colours or to add indicators for different kinds of files. ("ls -F --color").
But there are also ways to execute .c files directly, and of course
.py files which are run from source anyway.
There are standards for that. A text-based file can have a shebang
comment ("#! /usr/bin/bash", or similar) to let the shell know what interpreter to use. This lets you distinguish between "python2" and "python3", for example, which is a big improvement over Windows-style
file associations that can only handle one interpreter for each file
type.
And the *nix system distinguishes between executable files and
non-executables by the executable flag - that way you don't accidentally
try to execute non-executable Python files.
You do realise that gcc can handle some 30-odd different file types?
It's not a simple C compiler that assumes everything it is given is a C
file.
On Linux, you just write "make hello" - you don't need a makefile for
simple cases like that.
(And the "advanced AI" can figure out if it is
C, C++, Fortran, or several other languages.)
That's fine for programs that handle just one file type.
But I'm a little confused here. On the one hand, you are saying how terrible Linux is for not using file extensions. On the other hand, you
are saying how wonderful your own tools are because they don't need file extensions.
Could it be simply that file extensions are sometimes helpful, sometimes inconvenient or irrelevant, and mostly it all just works without much trouble?
On 17/12/2022 13:22, Bart wrote:
On 17/12/2022 06:07, antispam@math.uni.wroc.pl wrote:
When /I/ provide sources (that is, a representation that is one step
back from binaries), to build on Linux, then it will build on Linux.
They will have a dependency on a C compiler that can produce a ELF file, and I now stipulate either gcc or tcc.
See https://github.com/sal55/langs/tree/master/demo
This includes mc.c, a generated-C rendering of my M-on-Linux compiler.
You [antispam] will need gcc or tcc to create a binary on Linux;
instructions are at the link.
Once you have a working binary, you can try that on the one-file M
'true' sources in mc.ma, to create a new binary.
If that monolithic source file still doesn't cut it for you, I've
included an extraction program. The readme tells you how to run that,
and how to run the 2nd compiler on those discrete files to make a third compiler.
(I've briefly tested those instructions under WSL. It ought to work on
any 64-bit Linux including ARM, but I can't guarantee it. The C file is 32Kloc, and the .ma file is 25Kloc.
If it doesn't work, then forget it. I know it can be made to work, and
to do so via my one-file distributions.)
Bart <bc@freeuk.com> wrote:
On 17/12/2022 13:22, Bart wrote:
On 17/12/2022 06:07, antispam@math.uni.wroc.pl wrote:
When /I/ provide sources (that is, a representation that is one step
back from binaries), to build on Linux, then it will build on Linux.
They will have a dependency on a C compiler that can produce a ELF file, >>> and I now stipulate either gcc or tcc.
See https://github.com/sal55/langs/tree/master/demo
This includes mc.c, a generated-C rendering of my M-on-Linux compiler.
You [antispam] will need gcc or tcc to create a binary on Linux;
instructions are at the link.
Once you have a working binary, you can try that on the one-file M
'true' sources in mc.ma, to create a new binary.
It works on 64-bit AMD/Intel Linux.
More precisly, initial 'mc.c' compiled fine, but it could not
run 'gcc'. Namely, ARM gcc does not have '-m64' option. Once
I removed this it works.
I tested this using the following program:
proc main=
rsystemtime tm
os_getsystime(&tm)
println tm.second
println tm.minute
println tm.hour
println tm.day
println tm.month
println tm.year
end
BTW: I still doubt that 'mc.ma' expands to true source: do you
really write no comments in your code?
On 17/12/2022 06:07, antispam@math.uni.wroc.pl wrote:
Bart <bc@freeuk.com> wrote:
I don't agree. On Linux you do it with sources because it doesn't have a >> reliable binary format like Windows that will work on any machine. If
there are binaries, they might be limited to a particular Linux
distribution.
You do not get it. I create binaries that work on 10 year old Linux
and new one. And on distributions that I never tried.
I tried porting a binary from one ARM32 Linux machine to another; it
didn't work, even 2 minutes later. Maybe it should have worked and there
was some technical reason why my test failed.
But I have noticed that on Linux, distributing stuff as giant source
bundles seems popular. I assumed that was due to difficulties in using binaries.
Of course,
I mean that binaries are for specific architecture, separate
for i386 Linux and x86_64 Linux (that covers PC-s, I would have to
provide more if I wanted to support more architectures).
Concerning binary format, there were two: Linux started with a.out
and switched to ELF in second half of nineties.
(I don't understand that; a.out is a filename; ELF is a file format.)
You also ignore educational aspect: some folks fetch sources to
learn how things are done.
Sure. Android is open source; so is Firefox. While you can spend years reading through the 25,000,000 lines of Linux kernal code.
Good luck finding out how they work!
Here I'm concerned only with building stuff that works, and don't want
to know what directory structure the developers use.
Concerning not having extension: you can add one if you want,
moderatly popular choices are .exe or .elf.
But nobody does. Main problem is in forums like this: if I say
`hello.exe`, everyone knows that's a binary executable for Windows.
But
if I mention `hello`, how are you supposed to tell that I'm talking
about a Linux executable?
I know that Linux doesn't care about extensions, but people do. After
all it still uses, by convention, extensions like .c -s .o .a .so, so
why not actual binaries by convention?
But for using normal
Linux executable it should not matter if it is a shell script,
interpreted Python file or machine code. So exention should
not "give away" nature of executable.
You can have a neutral extension that doesn't give it away either. Using
no extension is not useful: is every file with no extension something
you can execute?
But there are also ways to execute .c files directly, and of course .py
files which are run from source anyway.
It simply doesn't make sense.
On Linux, I can see that executables are
displayed on consoles in different colours; what happened when there was
no colour used?
And having no extension
means that users are spared needless typing
Funny you should bring that up, because every time you run a /C
compiler/ on a /C source file/, you have to type the extension like this:
gcc hello.c
which also writes the output as a.exe or a.out, so you further need to
write at least:
gcc hello.c -o hello # hello.exe on Windows
I would only write this:
bcc hello
and it works out, by some very advanced AI, that I want to compile
hello.c into hello.exe. And once you have hello.exe, you can run it like this:
hello
You don't need to type .exe. So, paradoxically, having extensions means having to type them less often:
mm -pcl prog # old compiler: translate prog.m to prog.pcl
pcl -asm prog # prog.pcl to prog.asm
aa prog # prog.asm to prog.exe
prog # run it
At no point did I need to write an extension. It is implied by the
program I invoked.
No, but deriving the true sources from app.ma is trivial, since it is
basically a concatenation of the relevant files.
Not less trivial than running 'tar' (which is standard component
on Linux).
.ma is a text format; you can separate with a text editor if you want!
But you don't need to. Effectively you just do:
gcc app # ie. app.gz2
and it makes `app` (ie. an ELF binary 'app.').
* Needing to run './configure' first (this will not work on Windows...)
I saw one case then a guy tried to run './configure' on Windows NT
and Windows NT kept crashing.
Possibly you don't quite understand: aside from "./" being a syntax
error on Windows,
'configure' is a script full of Bash commands which
invoke all sorts of utilities from Linux. It is meaningless to attempt
to run it on Windows.
It would be like my bundling a Windows BAT file with sources intended to
be built on Linux.
It made a little progress and than
crashed, so that guy restarted it hoping that eventually it will
finish (after a week or two he gave up and used Linux). But
usually './configure' is not that bad. It make take a lot of
time, IME './configure' that run in seconds on Linux needed
several minutes on Windows.
It can takes several minutes on Linux too! Auto-conf-generated configure scripts can contain tens of thousands of lines of code.
And of course you need to install
essential dependencies, good program will tell you what you need
to install first, before running configure. But you need to
understand what they mean...
* Finding a 'make' /program/ (my gcc has a program called
mingw32-make.exe; is that the one?)
Probably. Normal advice for Windows folks is to install thing
called msys (IIUC it is msys2 now) which contains several tools
incuding 'make'. You are likely to get it as part of bigger
bundle, I am not up to date to tell you if this bundle will
be called 'gcc' or something else.
But that's just a cop-out. As I said above, it's like my delivering a
build system for Linux that requires so many Windows dependencies, that
you can only build by installing half of Windows.
I don't have any interest in this; I just want the binary!
Well, I provide Linux binaries, but only sources for Windows
users. One reason is that I have only Linux on my personal
machine, so to deal with Windows I need to lease a machine.
Different reason is that I an not paid for programming, I do
this because I like to program and to some degree to build
community.
I had the same problem, in reverse. I've spent money on RPis, cheap
Linux netbooks, spent endless time getting VirtualBox to work, and still don't have a suitable Linux machine that Just Works.
WSL is not interesting since it is still x64, and maybe things will work
that will not work on real Linux (eg. it can still run actual Windows
EXEs; what else is it allowing that wouldn't work on real Linux).
I've stopped this since no one has ever expressed any interest in seeing
my stuff work on Linux, especially on RPi where a very fast alternative
to C that ran on the actual board would have been useful.
Bart <bc@freeuk.com> wrote:
But I have noticed that on Linux, distributing stuff as giant source
bundles seems popular. I assumed that was due to difficulties in using
binaries.
Creating binaries that work on many system requires some effort.
Easiest way is to create them on oldest system that you expect to
be used: typically compile on Linux will try to take advantage
of features of processor and system, older system/processor
may lack those features and fail. As I wrote, one needs to limit dependencies or bundle them. Bundling may lead to very large
download size.
And do not forget to open source means that users can get the source.
If source is not available, most users will ignore your program.
Concerning binaries for ARM, they are a bit more problematic than
for Intel/AMD. Namely, there is a lot of different variants of
ARM processors and 3 different instruction encodings in popular
ARM have no support for 32-bit binaries. So, there is less
compatiblity than technically possible.
Things have structure, kernel is divided into subdirectories in
resonably logical way.
And there are tools like 'grep', it can
find relevant thing in seconds. This is not pure theory, I had
puzzling problem that binaries were failing on newer Linux
distributions. It took some time to solve, but another guy
hinted me that this may be tighthended "security" in kernel.
Even after the hint my first try did not work. But I was able
to find relevant code in the kernel and then it became clear
what to do.
Here I'm concerned only with building stuff that works, and don't want
to know what directory structure the developers use.
Concerning not having extension: you can add one if you want,
moderatly popular choices are .exe or .elf.
But nobody does. Main problem is in forums like this: if I say
`hello.exe`, everyone knows that's a binary executable for Windows.
It may be for Linux...
At no point did I need to write an extension. It is implied by the
program I invoked.
Implied extentions have trouble that somebody else my try to hijack
them. I use TeX system which produces .dvi files. IIUC they could
be easily mishandled by systems depending just on extion. And in
area of programming languages at least three languages compete for
.p extention.
Possibly you don't quite understand: aside from "./" being a syntax
error on Windows,
AFAIK '/' is legal in Windows pathnames (even though many programs
do not support it). I am not sure about leading dot.
'configure' is a script full of Bash commands which
invoke all sorts of utilities from Linux. It is meaningless to attempt
to run it on Windows.
You probably do not understand that 'configure' scripts use POSIX
commands.
It would be like my bundling a Windows BAT file with sources intended to
be built on Linux.
There are two important differences:
- COMMAND.COM is very crappy as command processor, unlike Unix shell
which from the start was designed as programming language. IIUC that
is changing with PowerShell.
- you compare thing which was designed to be portability layer with
platform specific thing.
It can takes several minutes on Linux too! Auto-conf-generated configure
scripts can contain tens of thousands of lines of code.
It depends on commands and script. Shell can execute thousends of
simple commands per second. On Linux most of time probably goes
to C compiler (which is called many times from 'confugure').
On Windows cost of process creation used to be much higher than
on Linux, so it is likely that most 'configure' time went to
process creation. Anyway, the same 'configure' script tended to
run 10-100 times slower on Windows than on Linux. I did not try
recently...
But that's just a cop-out. As I said above, it's like my delivering a
build system for Linux that requires so many Windows dependencies, that
you can only build by installing half of Windows.
POSIX utilities could be quite small. On Unix-like system one
could fit them in something between 1-2M. On Windows there is
trouble that some space saving ticks do not work (in Unix usual
trick is to have one program available under several names, doing
different thing depending on name). Also, for robustness they
may be staticaly linked. And people usually want versions with
most features, which are bigger than what is strictly necessary.
Still, that is rather small thing if you compare to size of
Windows.
Another story is size of C compiler and its header
files.
WSL is not interesting since it is still x64, and maybe things will work
that will not work on real Linux (eg. it can still run actual Windows
EXEs; what else is it allowing that wouldn't work on real Linux).
I've stopped this since no one has ever expressed any interest in seeing
my stuff work on Linux, especially on RPi where a very fast alternative
to C that ran on the actual board would have been useful.
Well, compiler that can not generate code for Pi is not very
interesting to run on RPi, even if it is very fast.
Your
latest M is step in good direction, but suffers due to gcc
compile time:
time ./mc -asm mc.m
M6 Compiling mc.m---------- to mc.asm
real 0m0.431s
user 0m0.347s
sys 0m0.079s
time ../mc mc.m
M6 Compiling mc.m---------- to mc
L:Invoking C compiler: gcc -omc mc.c -lm -ldl -s -fno-builtin
mc.c:2:32: warning: unknown option after '#pragma GCC diagnostic' kind [-Wpragmas]
#pragma GCC diagnostic ignored "-Wbuiltin-declaration-mismatch"
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
real 0m9.137s
user 0m8.746s
sys 0m0.386s
So 'mc' can generate C code in 0.431s, but then it takes '9.137s'
to compile generated C (IIUC Tiny C does not support ARM and
even on x86_64 compile command probably needs fixing).
And there seem to be per-program overhead:
time fred.nn/mc -asm hello.m
M6 Compiling hello.m------- to hello.asm
real 0m0.222s
user 0m0.186s
sys 0m0.032s
time fred.nn/mc hello.m
M6 Compiling hello.m------- to hello
L:Invoking C compiler: gcc -ohello hello.c -lm -ldl -s -fno-builtin hello.c:2:32: warning: unknown option after '#pragma GCC diagnostic' kind [-Wpragmas]
#pragma GCC diagnostic ignored "-Wbuiltin-declaration-mismatch"
real 0m1.596s
user 0m1.464s
sys 0m0.125s
'hello.m' is quite small, but is needs half of time of mc which
is 6000 times larger. And generated 'hello.c' is still 4381
lines.
On 32-bit Pi-s I have Poplog:
http://github.com/hebisch/poplog http://www.math.uni.wroc.pl/~hebisch/poplog/corepop.arm
For bootstrap one needs binary above. For me it works on
oryginal Raspberry Pi, Banana Pi, Orange Pi Pc, Orange Pi Zero.
They all have different ARM chips and run different version
of Linux, yet the same 'corepop.arm' works on all of them.
If you are interested you can look at INSTALL file in repo
above (skip quick install part that assumes tarball and go to
full install). Building uses had written 'configure', it
is very simple, but calls C compiler up to 4 times, so runtime
of 'configure' on Pi-s is noticeable (of order of 1 second).
Actual build (using 'make') takes few minutes, depending
on what was configured.
For massive files Poplog compiles much slower than your compiler
but usually much faster than gcc. However, main advantage
is that Poplog compiles to memory giving you impression of
interpreter, but generating machine code.
Let me add that there are actually two compilers, one compiling to
memory and separate one which generates assembly code. The second
compiler has low-level extenstions allowing faster object code.
Compiler compiling to memory is is significantly faster than
the one which generates assembly.
On 18/12/2022 17:17, antispam@math.uni.wroc.pl wrote:
As-is it failed on 64-bit ARM.
More precisly, initial 'mc.c' compiled fine, but it could not
run 'gcc'. Namely, ARM gcc does not have '-m64' option. Once
I removed this it works.
gcc doesn't have `-m64`, really? I'm sure I've used it even on ARM. (How
do you tell it it to generate ARM32 rather than ARM64 code?)
Bart <bc@freeuk.com> wrote:
On 17/12/2022 06:07, antispam@math.uni.wroc.pl wrote:
Bart <bc@freeuk.com> wrote:
Possibly you don't quite understand: aside from "./" being a syntax
error on Windows,
AFAIK '/' is legal in Windows pathnames (even though many programs
do not support it). I am not sure about leading dot.
For massive files Poplog compiles much slower than your compiler
but usually much faster than gcc. However, main advantage
is that Poplog compiles to memory giving you impression of
interpreter, but generating machine code.
That's what my 'mm' compiler does on Windows, using -run option. Or if I rename it 'ms', that is the default:
c:\mx>ms mm -run \qx\qq \qx\hello.q
Compiling mm.m to memory
Compiling \qx\qq.m to memory
Hello, World! 19-Dec-2022 15:00:34
(There's an issue ATM building ms with ms.)
But I can't do this via the C target.
Bart <bc@freeuk.com> wrote:
I know that Linux doesn't care about extensions, but people do. After
all it still uses, by convention, extensions like .c -s .o .a .so, so
why not actual binaries by convention?
Here you miss virtue of simplicity: binaries are started by kernel
and you pass filename of binary to the system call. No messing
with extentions there. There are similar library calls that
do search based on PATH, again no messing with extentions.
It simply doesn't make sense.
It makes sense if you know that executable in the PATH is simultaneousy
shell command. You see, there are folks which really do not like
useless clutter in their command lines. And before calling
executable from a shell script you may wish to check if it is available. Having different extention for calling and for access as normal
file would complicate scripts.
On 19/12/2022 06:15, antispam@math.uni.wroc.pl wrote:
Bart <bc@freeuk.com> wrote:
I know that Linux doesn't care about extensions, but people do. After
all it still uses, by convention, extensions like .c -s .o .a .so, so
why not actual binaries by convention?
Here you miss virtue of simplicity: binaries are started by kernel
and you pass filename of binary to the system call. No messing
with extentions there. There are similar library calls that
do search based on PATH, again no messing with extentions.
I don't get this. Do you mean that inside a piece of code (ie. written
once and executed endless times), it is better to write run("prog")
instead of run("prog.exe"), because it saves 4 keystrokes?
It simply doesn't make sense.
It makes sense if you know that executable in the PATH is simultaneousy shell command. You see, there are folks which really do not like
useless clutter in their command lines. And before calling
executable from a shell script you may wish to check if it is available. Having different extention for calling and for access as normal
file would complicate scripts.
In every context I've been talking about where extensions have been
optional and have been inferred, you have always been able to write full extensions if you want. This would be recommended inside a script run
myriad times to make it clear to people reading or maintaining it.
People have mentioned that on Linux you could optionally name
executables with ".exe" or ".elf" extension. If 'gcc' (the main binary
driver program of gcc, not gcc as a broader concept - you see the
problems you get into!) had been named "gcc.exe", would you have had to
type this every time you ran it:
gcc.exe hello.c
If so, then I think I can see the real reason why extensions are empty!
In a Linux terminal shell, there apparently is no scope for informality
or user-friendliness at all.
This has lead me to thinking about how command line parameters are
separated. On either OS you normally type this:
gcc a.c b.c c.c
You can't do this, separate with commas, as the comma becomes part of
each filename:
gcc a.c, b.c, c.c
That applies also to my bcc, but there, you CAN have comma-separated
items inside an @file; with gcc, that still fails.
So, what's going on here: is it an OS shell misfeature, or what?
Well it's not the OS on Windows, since 'T.BAT a,b,c' will process a, b,
c as separate 'a b c' items inside the script (not as "a," etc). (I
can't test how it works on Linux.)
On 18/12/2022 13:05, David Brown wrote:
On 17/12/2022 14:22, Bart wrote:
For data files, it can often be convenient to have an extension
indicating the type - and it is as common on Linux as it is on Windows
to have ".odt", ".mp3", etc., on data files.
It's convenient for all files. And before you say, I can add a .exe
extension if I want: I don't want to have to write that every time I run
that program.
People use extensions where they are useful, and skip them when they
are counter-productive (such as for executable programs).
I can't imagine all my EXE (and perhaps BAT files) all having no
extensions. Try and envisage all your .c files have no extensions by
default. How do you even tell that are C sources and not Python or not executables?
When you are writing code, and you have a function "twiddle" and an
integer variable "counter", you call them "twiddle" and "counter".
You don't call them "twiddle_func" and "counter_int". But maybe
sometimes you find it useful - it's common to write "counter_t" for a
type, and maybe you'd write "xs" for an array rather than "x".
Filenames can follow the same principle - naming conventions can be
helpful, but you don't need to be obsessive about it or you end up
with too much focus on the wrong thing.
But you /do/ write twiddle.c, twiddle.s, twiddle.o, twiddle.cpp,
twiddle.h etc? Yet the most important file of all, is just plain 'twiddle'!
In casual writing or conversation, how to do distinguish 'twiddle the
binary executable' from 'twiddle the folder', from 'twiddle the
application' (an installation) , from 'twiddle' the project etc, without having to use that qualification?
Using 'twiddle.exe' does that succinctly and unequivocally.
On *nix, every file with the executable flag can be executed - that's
what the flag is for.
Sometimes it is convenient to be able to see which files in a
directory are executables, directories, etc. That's why "ls" has
flags for colours or to add indicators for different kinds of files.
("ls -F --color").
As I said, if it's convenient for data and source files, it's convenient
for all files.
But there are also ways to execute .c files directly, and of course
.py files which are run from source anyway.
There are standards for that. A text-based file can have a shebang
comment ("#! /usr/bin/bash", or similar) to let the shell know what
interpreter to use. This lets you distinguish between "python2" and
"python3", for example, which is a big improvement over Windows-style
file associations that can only handle one interpreter for each file
type.
That is invasive. And taking something that is really an attribute of a
file name, in having it not only inside the file, but requiring the file
to be opened and read to find out.
(Presumably every language that runs on Linux needs to accept '#' as a
line comment? And you need to build it in to every one of 10,000 source
files the direct location of the Python2 or Python3 installation on that machine? Is that portable across OSes? But I expect it's smarter than
that.)
With Python, you're still left with the fact that you see a file with a
.py extension, and don't know if it's Py2 or Py3, or Py3.10 or Py3.11,
or whether it's a program that works with any version. It is a separate problem from having, as convention, no extensions for ELF binary files.
And the *nix system distinguishes between executable files and
non-executables by the executable flag - that way you don't
accidentally try to execute non-executable Python files.
(So there are files that contain Python code that are non-executable?
Then what is the point?)
You do realise that gcc can handle some 30-odd different file types?
That doesn't change the fact that probably 99% of the time I run gcc, it
is with the name of a .c source file. And 99.9% of the times when I
invoke it on prog.c as the first or only file to create an executable,
then I want to create prog.exe.
So its behaviour is unhelpful. After the 10,000th time you have to type
.c, or backspace over .c to get at the name itself to modify, it becomes tedious.
Now it's not that hard to write a wrapper script or program on top of gcc.exe, but if it isn't hard, why doesn't it just do that?
It's not a simple C compiler that assumes everything it is given is a
C file.
As I said, that is not helpful for me. Also, how many file types does
'as' accept? As that also requires the full extension, and also,
bizarrely, generates `a.out` as the object file name.
If you intend to assemble three .s files to object files, using separate
'as' invocations, they will all be called a.out!
That would be crass even for a toy program written by a student. And yet
here it is a mainstream product used by million of people.
All my language programs (and many of my apps), have a primary type of
input file, and will default to that file extension if omitted. Anything
else (eg .dll files) need the full extension.
Here's something funny: take hello.c and rename to 'hello', with no extension. If I try and compile it:
gcc hello
it says: hello: file not recognised: file format not recognised. Trying
'gcc hello.' is worse: it can't see the file at all.
So first, on Linux, where file extensions are supposed to be optional,
gcc can't cope with a missing .c extension; you have to provide extra
info. Second, on Linux, "hello" is a distinct file from "hello.".
With bcc, I just have to type "bcc hello." to make it work. A trailing
dot means an empty extension.
On Linux, you just write "make hello" - you don't need a makefile for
simple cases like that.
OK... so how does 'make' figure out the file extension?
'Make' anyway has different behaviour:
* It can choose not to compile
* On Windows, it says this:
c:\yyy>make hello
cc hello.c -o hello
process_begin: CreateProcess(NULL, cc hello.c -o hello, ...) failed.
make (e=2): The system cannot find the file specified.
<builtin>: recipe for target 'hello' failed
make: *** [hello] Error 2
* I also use several C compilers; how does make know which one I intend?
How do I pass it options?
If I give another example:
c:\c>bcc cipher hmac sha2
Compiling cipher.c to cipher.asm
Compiling hmac.c to hmac.asm
Compiling sha2.c to sha2.asm
Assembling to cipher.exe
it just works. 'make cipher hmac sha2' doesn't, not even in WSL.
(And the "advanced AI" can figure out if it is C, C++, Fortran, or
several other languages.)
No, it can't. If I have hello.c and hello.cpp, it will favour the .c file.
File extensions are tremendously helpful. But that doesn't mean you have
to keep typing them! They just have to be there.
On 18/12/2022 13:05, David Brown wrote:
On 17/12/2022 14:22, Bart wrote:
When you are writing code, and you have a function "twiddle" and an
integer variable "counter", you call them "twiddle" and "counter".? You don't call them "twiddle_func" and "counter_int".? But maybe sometimes
you find it useful - it's common to write "counter_t" for a type, and
maybe you'd write "xs" for an array rather than "x".? Filenames can
follow the same principle - naming conventions can be helpful, but you don't need to be obsessive about it or you end up with too much focus on the wrong thing.
But you /do/ write twiddle.c, twiddle.s, twiddle.o, twiddle.cpp,
twiddle.h etc? Yet the most important file of all, is just plain 'twiddle'!
If you intend to assemble three .s files to object files, using separate
'as' invocations, they will all be called a.out!
That would be crass even for a toy program written by a student. And yet
here it is a mainstream product used by million of people.
* I also use several C compilers; how does make know which one I intend?
How do I pass it options?
If I give another example:
c:\c>bcc cipher hmac sha2
Compiling cipher.c to cipher.asm
Compiling hmac.c to hmac.asm
Compiling sha2.c to sha2.asm
Assembling to cipher.exe
it just works. 'make cipher hmac sha2' doesn't, not even in WSL.
On 18/12/2022 17:17, antispam@math.uni.wroc.pl wrote:
Bart <bc@freeuk.com> wrote:
On 17/12/2022 13:22, Bart wrote:
On 17/12/2022 06:07, antispam@math.uni.wroc.pl wrote:
I tested this using the following program:
proc main=
rsystemtime tm
os_getsystime(&tm)
println tm.second
println tm.minute
println tm.hour
println tm.day
println tm.month
println tm.year
end
It's funny you picked on that, because the original version of my
hello.m also printed out the time:
proc main=
println "Hello World!",$time
end
This was to ensure I was actually running the just built-version, and
not the last of the 1000s of previous ones. But the time-of-day support
for Linux wasn't ready so I left it out.
I've updated the mc.c/mc.ma files (not hello.m, I'm sure you can fix that).
However getting this to work on Linux wasn't easy as it kept crashing.
The 'struct tm' record ostensibly has 9 fields of int32, so has a size
of 36 bytes. And on Windows it is. But on Linux, a test program reported
the size as 56 bytes.
Doing -E on that program under Linux, the struct actually looks like this:
struct tm
{
int tm_sec;
int tm_min;
int tm_hour;
int tm_mday;
int tm_mon;
int tm_year;
int tm_wday;
int tm_yday;
int tm_isdst;
long int tm_gmtoff;
const char *tm_zone;
};
16 extra byte for fields not mentioned in 'man' docs, plus 4 bytes
alignment account for the 20 bytes. This is typical of the problems in adapting C APIs to the FFIs of other languages.
BTW: I still doubt that 'mc.ma' expands to true source: do you
really write no comments in your code?
The file was detabbed and decommented, as the comments would be full of ancient crap, mainly debugging code that never got removed. I've tidied
most of that up, and now the file is just detabbed (otherwise things
won't line up properly). Note the sources are not heavily commented anyway.
It will always be a snapshot of the actual sources, which are not kept on-line and can change every few seconds.
Bart <bc@freeuk.com> wrote:
This has lead me to thinking about how command line parameters are
separated. On either OS you normally type this:
gcc a.c b.c c.c
You can't do this, separate with commas, as the comma becomes part of
each filename:
gcc a.c, b.c, c.c
That applies also to my bcc, but there, you CAN have comma-separated
items inside an @file; with gcc, that still fails.
Why would you do such silly thing? If you really want you can
redefine 'gcc' so that it strips trailing commas (that is
trivial). If you like excess characters you can type longer
thing like:
echo gcc a.c, b.c, c.c | tr -d ',' | bash
So, what's going on here: is it an OS shell misfeature, or what?
KISS principle. Commas are legal in filenames and potentially
useful. On command line spaces work fine. If you really need
splitting to work differently there are resonably simple ways
to do this, most crude is above.
BTW: travelling between UK and other countries do you complain
that cars drive on wrong side of the road?
Well it's not the OS on Windows, since 'T.BAT a,b,c' will process a, b,
c as separate 'a b c' items inside the script (not as "a," etc). (I
can't test how it works on Linux.)
There is IFS variable which lists characters used for word splitting,
you can put comma there together with whitspace. I never used it
myself, but it is used extensively in hairy shell scripts like
'configure'.
In *nix, the shell (not the OS) is responsible for many aspects of
parsing command lines, including splitting up parameters and expanding wildcards in filenames. So on Linux, writing "gcc a.c, b.c, c.c" in
bash will call gcc with three parameters - "a.c,", "b.c,", and "c.c".
On Windows, the standard "DOS Prompt" command-line terminal does very
little of this. (I don't know the details of Powershell. And if you
use a different shell on Windows, like bash from msys, you get the
behaviour of that shell.)
On 20/12/2022 03:44, antispam@math.uni.wroc.pl wrote:
Bart <bc@freeuk.com> wrote:
This has lead me to thinking about how command line parameters are
separated. On either OS you normally type this:
gcc a.c b.c c.c
You can't do this, separate with commas, as the comma becomes part of
each filename:
gcc a.c, b.c, c.c
That applies also to my bcc, but there, you CAN have comma-separated
items inside an @file; with gcc, that still fails.
Why would you do such silly thing? If you really want you can
redefine 'gcc' so that it strips trailing commas (that is
trivial). If you like excess characters you can type longer
thing like:
echo gcc a.c, b.c, c.c | tr -d ',' | bash
So, what's going on here: is it an OS shell misfeature, or what?
KISS principle. Commas are legal in filenames and potentially
useful. On command line spaces work fine. If you really need
splitting to work differently there are resonably simple ways
to do this, most crude is above.
BTW: travelling between UK and other countries do you complain
that cars drive on wrong side of the road?
Well it's not the OS on Windows, since 'T.BAT a,b,c' will process a, b,
c as separate 'a b c' items inside the script (not as "a," etc). (I
can't test how it works on Linux.)
There is IFS variable which lists characters used for word splitting,
you can put comma there together with whitspace. I never used it
myself, but it is used extensively in hairy shell scripts like
'configure'.
An important issue here is that the "OS" is not involved in any of this, either on Windows or on Linux.
In *nix, the shell (not the OS) is responsible for many aspects of
parsing command lines, including splitting up parameters and expanding wildcards in filenames. So on Linux, writing "gcc a.c, b.c, c.c" in
bash will call gcc with three parameters - "a.c,", "b.c,", and "c.c".
On Windows, the standard "DOS Prompt" command-line terminal does very
little of this. (I don't know the details of Powershell. And if you
use a different shell on Windows, like bash from msys, you get the
behaviour of that shell.) So if you have a normal "DOS Prompt" and
write "gcc a.c, b.c, c.c" then the program "gcc" is called with /one/ parameter. It's up to the program to decide how to parse these.
Typically it will use one of several different WinAPI calls depending on whether it wants the abomination that is "wide characters", or UTF-8, or
to hope that everything is simple ASCII. If a program wants to parse
the string itself using commas as separators, it can do that too.
Of course most programs - especially those that come from a *nix
heritage - will choose to parse in the same way as is done by *nix shells.
I did not know that the batch file interpreter handled commas
differently like this. Who says you never learn things on Usenet? :-)
On 18/12/2022 18:09, Bart wrote:
A key point here is that almost every general-purpose OS, other than
Windows, in modern use on personal computers is basically POSIX
compliant.
Maybe you haven't done much Python programming and have only worked with small scripts. But like any other language, bigger programs are split
into multiple files or modules - only the main program file will be executable. So if a big program has 50 Python files, only one of them
will normally be executable and have the shebang and the executable
flag. (Sometimes you'll "execute" other modules to run their tests
during development, but you'd likely do that as "python3 file.py".)
You do realise that gcc can handle some 30-odd different file types?
That doesn't change the fact that probably 99% of the time I run gcc,
it is with the name of a .c source file. And 99.9% of the times when I
invoke it on prog.c as the first or only file to create an executable,
then I want to create prog.exe.
OK. So gcc should base its handling of input on what /you/ do, never
mind the rest of the world?
That's fine for your own tools, but not for
gcc.
In *nix, the dot is just a character, and file extensions are just part
of the name. You can have as many or as few as you find convenient and helpful.
If you intend to assemble three .s files to object files, using
separate 'as' invocations, they will all be called a.out!
That would be crass even for a toy program written by a student. And
yet here it is a mainstream product used by million of people.
All my language programs (and many of my apps), have a primary type of
input file, and will default to that file extension if omitted.
Anything else (eg .dll files) need the full extension.
Here's something funny: take hello.c and rename to 'hello', with no
extension. If I try and compile it:
gcc hello
it says: hello: file not recognised: file format not recognised.
Trying 'gcc hello.' is worse: it can't see the file at all.
How is that "funny" ? It is perfectly clear behaviour.
gcc supports lots of file types. For user convenience it uses file extensions to tell the file type unless you want to explicitly inform it
of the type using "-x" options.
<https://gcc.gnu.org/onlinedocs/gcc/Overall-Options.html>
"hello" has no file extension, so the compiler will not assume it is C. (Remember? gcc is not just a simple little dedicated C compiler.) Files without extensions are assumed to be object files to pass to the linker,
and your file does not fit that format.
"hello." is a completely different file name - the file does not exist.
It is an oddity of DOS and Windows that there is a hidden dot at the end
of files with no extension - it's a hangover from 8.3 DOS names.
Yes. It's the only sane way, and consistent with millions of programs spanning 50 years on huge numbers of systems.
With bcc, I just have to type "bcc hello." to make it work. A trailing
dot means an empty extension.
When you make your own little programs for your own use, you can pick
your own rules.
Do you have a program called "cc" on your path? It's unlikely. "cc" is the standard name for the system compiler, which may be gcc or may be something else entirely.
* I also use several C compilers; how does make know which one I
intend? How do I pass it options?
It uses the POSIX standards. The C compiler is called "cc", the flags passed are in the environment variable CFLAGS.
If that's not what you want, write a makefile.
If I give another example:
c:\c>bcc cipher hmac sha2
Compiling cipher.c to cipher.asm
Compiling hmac.c to hmac.asm
Compiling sha2.c to sha2.asm
Assembling to cipher.exe
it just works. 'make cipher hmac sha2' doesn't, not even in WSL.
(And the "advanced AI" can figure out if it is C, C++, Fortran, or
several other languages.)
No, it can't. If I have hello.c and hello.cpp, it will favour the .c
file.
Sorry, I should have specified that the "advanced AI" can do it on an advanced OS, such as every *nix system since before Bill Gates found
MS-DOS is a dustbin.
Bart <bc@freeuk.com> wrote:
It will always be a snapshot of the actual sources, which are not kept
on-line and can change every few seconds.
You are misusing git and github. git is "source control" system.
At least from my point of view (there is lot of flame wars discussing
what source control should do) main task of source control is
to store all significant versions of software and allow resonable
easy retrival of any version. Logically got stores separate
source tree for each version (plus some meta info like log messages).
Done naively it would lead to serious bloat, which 1547 versions
it would be almost 1547 times larger than single version. git
uses compression to reduce this. AFAICS actual sources of your
projects are about 4-5M. With normal git use I would expect
(compressed) history to add another 5-10M (if there are a lot of
deletions than history would be bigger). Your repo is bigger than
that probably due to generated files and .exe. Note: I understand
that if you write in your own language, than bootstrap is a problem.
But for boostrap mc.c is enough. OK, you want want be independent
from C, so mayb .exe. But .ma files just add bloat. Note that
github has release feature, people who want just binaries or single
verion can fetch release. And many projects having bootstrap
problem say: if you do not have compiler fetch earler binary
and use it to build the system. Or they add extra generated things
to releases but do not keep them in source repositiory.
Exactly. You just have a very DOS-biased view as to when they are
helpful, and when they are not. It's a backwards and limited view due
to a lifetime of living with a backwards and limited OS.
On 20/12/2022 11:55, antispam@math.uni.wroc.pl wrote:
Bart <bc@freeuk.com> wrote:
It will always be a snapshot of the actual sources, which are not kept
on-line and can change every few seconds.
You are misusing git and github. git is "source control" system.
At least from my point of view (there is lot of flame wars discussing
what source control should do) main task of source control is
to store all significant versions of software and allow resonable
easy retrival of any version. Logically got stores separate
source tree for each version (plus some meta info like log messages).
Done naively it would lead to serious bloat, which 1547 versions
it would be almost 1547 times larger than single version. git
uses compression to reduce this. AFAICS actual sources of your
projects are about 4-5M. With normal git use I would expect
(compressed) history to add another 5-10M (if there are a lot of
deletions than history would be bigger). Your repo is bigger than
that probably due to generated files and .exe. Note: I understand
that if you write in your own language, than bootstrap is a problem.
But for boostrap mc.c is enough. OK, you want want be independent
from C, so mayb .exe. But .ma files just add bloat. Note that
github has release feature, people who want just binaries or single
verion can fetch release. And many projects having bootstrap
problem say: if you do not have compiler fetch earler binary
and use it to build the system. Or they add extra generated things
to releases but do not keep them in source repositiory.
DB:
Exactly. You just have a very DOS-biased view as to when they are helpful, and when they are not. It's a backwards and limited view due
to a lifetime of living with a backwards and limited OS.
So much negativity here.
I get the impression that everything I try is viewed negatively.
At least, I don't remember anyone saying, What a great idea, Bart!
Or,
Yeah, I'd like that, but unfortunately the way Linux works makes that impractical.
Instead, it would be, Yeah, that's what you would expect from a rubbish
OS that Bill Gates found in a bin.
So much negativity here.[... To David and Waldek:]
You two aren't going to be happy until my language is a clone of C,
with tools that work exactly the same way they do on Unix. But then
you're going to say, what's the point?
At least, I don't remember anyone saying, What a great idea, Bart!
Or, Yeah, I'd like that, but unfortunately the way Linux works makes
that impractical.
* Linux, sadly, has acquired a degree of bloat. Eg, "man gcc" comes
to some 300 pages, compared with the two pages of "man cc" in the
7th Edition version. Basically, it's always easier to add more
to an existing facility that to take stuff out. Grr! We used to
grumble when the binary of a fully-featured browser went to over
a megabyte. Now we scarcely turn a hair at the size of Firefox,
or the number of processes it spawns. Grr.
You [and probably Dmitry] seem to have a very weird idea of what Unix /is/.
But what you seem to fail to appreciate is that very little of Unix is
laid down in concrete.
On 21/12/2022 01:42, Bart wrote:
You of course will disagree, since whatever Unix does, no matter how
ridiculous or crass, is perfect, and every other kind of behaviour is
rubbish.
Yes.
But then, I would not normally keep a thousand files in one directory. I think even MS-DOS has supported directory trees since version 2.x.
You of course will disagree, since whatever Unix does, no matter how ridiculous or crass, is perfect, and every other kind of behaviour is rubbish.
On 20/12/2022 06:56, David Brown wrote:
On 18/12/2022 18:09, Bart wrote:
A key point here is that almost every general-purpose OS, other than
Windows, in modern use on personal computers is basically POSIX
compliant.
POSIX compliant means basically being a clone of Unix with all the same restrictions and stupid quirks?
Maybe you haven't done much Python programming and have only worked
with small scripts. But like any other language, bigger programs are
split into multiple files or modules - only the main program file will
be executable. So if a big program has 50 Python files, only one of
them will normally be executable and have the shebang and the
executable flag. (Sometimes you'll "execute" other modules to run
their tests during development, but you'd likely do that as "python3
file.py".)
Oh, just like Windows then?
Obviously, all 50 modules will contain executable code. You probably
mean that only the lead module can be launched by the OS and needs
special permissions.
You do realise that gcc can handle some 30-odd different file types?
That doesn't change the fact that probably 99% of the time I run gcc,
it is with the name of a .c source file. And 99.9% of the times when
I invoke it on prog.c as the first or only file to create an
executable, then I want to create prog.exe.
OK. So gcc should base its handling of input on what /you/ do, never
mind the rest of the world?
No, based on what LOTS of people do. gcc is used as a /C/ compiler, and
is probably only ever used as a C compiler.
Maybe this is acceptable to
you:
gcc prog.c -oprog -lm
./prog
But I prefer:
bcc prog
prog
Who wouldn't?
Why would I bother with such stone-age rubbish? (And that hardly ever
works.)
On 21/12/2022 11:07, Bart wrote:
[...]
So much negativity here.[... To David and Waldek:]
You two aren't going to be happy until my language is a clone of C,
with tools that work exactly the same way they do on Unix. But then
you're going to say, what's the point?
You [and probably Dmitry] seem to have a very weird idea of what Unix /is/. To really understand why many of us have been happy users of Unix [and somewhat less so of Linux*] for several decades, you need to understand the history, what came before, and how Unix then evolved. I don't intend to write an essay here; there are books on the subject.
But what you seem to fail to appreciate is that very little of Unix is
laid down in concrete. It would take major surgery to change the file system significantly; you are probably also stuck with the "exec"
family of system calls; you would be unwise to tamper too much with
the basic security mechanisms. But thereafter, it's entirely up to
you.
You're bright enough to be able to write your own language and compiler. So you're surely bright enough to write your own shell, or
to tinker with one of those already available -- they /all/ came into existence because some other bright person wanted something different.
Bright enough to write wrappers for things where you would prefer the defaults to be different, to write your own editor, your own tools for
all purposes. All, every single one, of those supplied "by default"
again came into being because someone decided they wanted it and wrote
the requisite code. Sources are freely available, so if you want
something different and don't want to write your own, you can play
with the code that someone else wrote. Entirely up to you.
When David says "you can do X", he doesn't mean "you /have/ to
do X". There is almost no compulsion. All the tools are there, use
them as you please. When you complain about some aspect of "gcc" or
"make" or whatever, you're actually complaining that people who gave
their time and expertise freely to provide a tool that /they/ wanted,
haven't done so to /your/ specification. Well, shucks.
To give one example, you have been wittering recently about
the fact that "cc hello; hello" doesn't, as you would like, find and
compile a program whose source is in "hello.c", put the binary into
"hello", and run it. But you can write your own almost trivially;
it's a "one-line" shell script [for large values of "one", but that's
to provide checks rather than because it's complicated]. You complain
that you have to write "./hello" rather than just "hello"; but that's because "." is not in your "$PATH", which is set by you, not because Unix/Linux insists on extra verbiage. If you need further help, just
ask. But I'd expect you to be able to work it out rather than wring
your hands and flap around helplessly [or blame Unix for it].
But you can write your own almost trivially;
it's a "one-line" shell script
[...]
At least, I don't remember anyone saying, What a great idea, Bart!
Or, Yeah, I'd like that, but unfortunately the way Linux works makes
that impractical.
Perhaps you would tell us what great ideas you'd like "us" to consider? The things I recall you telling us are things that existed
long ago in other languages, such as 1-based arrays, line-based syntax,
or case insensitivity.
Any Linux shell made a terrible CLI, but I guess it was designed for
gurus rather than ordinary people.
On 21/12/2022 12:07, Bart wrote:
So much negativity here.
I have long experience with MS-DOS and Windows,
and long experience with
*nix.
DOS is absolute shite in comparison - it was created as a cheap
knock-off of other systems, thrown together quickly for a throw-away marketing project by IBM.
Unfortunately IBM forgot to throw away the
project and it was accidentally successful,
resulting in the world being
stuck with hardware, software and a processor ISA that were known to be third-rate
outdated cheapo solutions at the time the IBM PC was first
released. Those turds have been polished a great deal in the last 35
years or so
processors are very impressive engineering - but turds they remain at
their core. While some designs were planned to be forward compatible
with future enhancements (like the 68k processor architecture, or the
BBC MOS operating system), and some were designed to be compatible with everything above a set minimum (like Unix), x86 and DOS then Windows
have been saddled with backwards compatibility as their prime
motivation.
But I don't understand how you can take personal offence when I talk
about operating systems, or how you end up thinking it was a criticism
of you or your language.
On 22/12/2022 16:21, David Brown wrote:
On 21/12/2022 01:42, Bart wrote:
You of course will disagree, since whatever Unix does, no matter how
ridiculous or crass, is perfect, and every other kind of behaviour is
rubbish.
Yes.
But then, I would not normally keep a thousand files in one directory.
I think even MS-DOS has supported directory trees since version 2.x.
You've obviously never written programs for other people to run on their
own PCs. How do /you/ know how other people will organise their files?
Who are you to tell them how to do so?
And it might in any case be up to third party apps how files are
generated or your client's machine.
But my point about '* *.c', which you've chosen to ignore, is valid even
for ten files; it's just wrong.
It might be acceptable within a higher level language where each
wildcard spec expands to a list of files which itself is a nested
element of the paramter list. But it doesn't work is you just
concatenate everything into one giant list; there are too many ambiguities.
Of course, will never agree there's anything wrong with it; you will
defend Linux to the death. Or you will point that you can do X, Y and Z
to turn off this 'globbing', which now causes problems to programs that depend on, and which it is now up to each customer to do so persistently
on their machines.
On 22/12/2022 13:03, David Brown wrote:
On 21/12/2022 12:07, Bart wrote:
So much negativity here.
I have long experience with MS-DOS and Windows,
So have I.
and long experience with *nix.
I looked into it every few years; it always looked shite to me.
However, I should say I have little interest in operating systems
anyway. DOS was fine because it didn't get in my way. It provided a file system, could copy files, launch programs etc, and it didn't cut my productivity and sanity in half by throwing in case-sensitivity. What
else did I need?
I expect you didn't like DOS because it doesn't have the dozens of toys
that you came to rely on in Unix, including a built-in C compiler; what luxury!
It's because DOS was so sparse that I have few dependencies on it; and
my stuff can build on Linux more easily than Linux programs can build on Windows. (AIUI, most won't; you need to use CYGWIN or MSYS or WSL, but
then you don't get a bona fide Windows executable that customers can run directly.)
DOS is absolute shite in comparison - it was created as a cheap
knock-off of other systems, thrown together quickly for a throw-away
marketing project by IBM.
This is from who used, what was it, a Spectrum machine?
I was involved in creating 8-bit business computers at the time, and
looked down on such things. (But it was also my job to investigate
similar, low-cost designs for hobbyist computers as an area of expansion.)
BTW our machines used a rip-off of CP/M. My boss approached Digital
Research but couldn't come to an agreement on licensing. So we (not me though) created a clone. So why is saving money a bad thing?
I don't know exactly what you expected from an OS that ran on a 64KB
machine, which wasn't allowed to use more than about 8KB.
And, where /were/ the PCs with Unix in those days? Where could you buy
one? Would you be able to do much on it other than endlessly configure
stuff to make it work? Could you create binaries that were guaranteed to
work with any other Unix?
How unfriendly would it have been to supply apps as software bundles
that would take an age to build on a dual-floppy machine, with users
havin to keep feeding it floppies?
I think you just have little experience of that world of creating
products for low-end consumer PCs.
IME Linux systems were poor, amateurish attempts at an OS where lots of things just didn't work, until the early 2000s. GUIs came late too, and looked dreadful. By comparison, Microsoft Windows looked professional.
Yes you had to pay for it; is that what this is about, that Linux is free?
Unfortunately IBM forgot to throw away the project and it was
accidentally successful,
Good.
resulting in the world being stuck with hardware, software and a
processor ISA that were known to be third-rate
The IBM PC was definitely more advanced than by 8-bit business machine,
if not that much faster despite an internal 16-bit processor.
The 8088/86/286 had some disappointing limitations, which were fixed
with the 80386.
outdated cheapo solutions at the time the IBM PC was first released.
Those turds have been polished a great deal in the last 35 years or so
The architecture was open. There was a huge market in add-on
peripherals, and they came with drivers that worked. Good luck in
finding equivalent support in 1990s for even a printer driver under Linux.
- some versions of Windows are okay, and modern x86-64
processors are very impressive engineering - but turds they remain at
their core. While some designs were planned to be forward compatible
with future enhancements (like the 68k processor architecture, or the
BBC MOS operating system), and some were designed to be compatible
with everything above a set minimum (like Unix), x86 and DOS then
Windows have been saddled with backwards compatibility as their prime
motivation.
Which has been excellent. Until they chose not to support 16-bit
binaries under 64-bit Windows.
But I don't understand how you can take personal offence when I talk
about operating systems, or how you end up thinking it was a criticism
of you or your language.
I get annoyed when people openly diss Windows, or MSDOS, simply for not
being Linux.
The alternative in DOS and Windows has always been to buy additional
tools that *nix users take for granted. And those tools always have to include /everything/. So while a Pascal compiler for *nix just needs to
be a Pascal compiler - because there are editors, build systems,
debuggers, libraries, assemblers and linkers already - on DOS/Windows
you had to get Turbo Pascal or Borland Pascal which had everything
included.
Do I like the fact that *nix has always come with a wide range of general-purpose tools? Yes, I most surely do!
On 22/12/2022 17:59, Bart wrote:
But my point about '* *.c', which you've chosen to ignore, is valid
even for ten files; it's just wrong.
It might be acceptable within a higher level language where each
wildcard spec expands to a list of files which itself is a nested
element of the paramter list. But it doesn't work is you just
concatenate everything into one giant list; there are too many
ambiguities.
Of course, will never agree there's anything wrong with it; you will
defend Linux to the death. Or you will point that you can do X, Y and
Z to turn off this 'globbing', which now causes problems to programs
that depend on, and which it is now up to each customer to do so
persistently on their machines.
I can't figure out what you are worrying about here.
In any shell, in any OS, for any program, if you write "prog *" the
program is run with a list of all the files in the directory.
If you
wrote "prog * *.c", it will be started with a list of all the files,
followed by a list of all the ".c" files.
It's the same in DOS, Linux, Windows, Macs, or anything else you like.
It's the same for any shell.
The difference is that for some shells (such as Windows PowerShell or
bash), the shell does the work of finding the files and expanding the wildcards because this is what /every/ program needs - there's no point
in repeating the same code in each program. In other shells, such as
DOS "command prompt", every program has to have that functionality added
to the program.
Well, I say "every program" supports wildcards for filenames - I'm sure
there are some DOS/Windows programs that don't. But most do.
That will be up to individual programs whether they accept wildcards for filenames, and what they do about them. If the input is "*", what kinds
of application would be dealing with an ill-matched collection of files including all sorts of junks that happens to be lying around?
It would be very specific. BTW if I do this under WSL:
vim *.c
Then I was disappointed that I didn't get hundreds of edit windows for
all those files. So even under Linux, sometimes expansion doesn't
happen. (What magic does vim use to get the OS to see sense?)
Usually the last thing you want is for the OS (or whatever is
responsible for expanding those command line params before they get to
the app) is to just expand EVERYTHING willy-nilly:
* Maybe the app needs to know the exact parameters entered (like my
showargs program).
Maybe they are to be stored, and passed on to
different parts of an app as needed.
* Maybe they are to be passed onto to another program, where it's going
to be much easier and tidier if they are unexpanded:
c:\mx>ms showargs * *.c
1 *
2 *.c
Here 'ms', which runs 'showargs' as a script, sees THREE parameters: showargs, * and *.c; It arranges for the last two to be passed as input
to the program being run.
* Maybe the app's inputs are mathematical expressions so that you want
"A*B" and not a list of files that start with A and end with B!
* But above all, it simply doesn't work, not when you have expandable
params interspersed with other expandable ones, or even ordinary params, because everything just merges together.
So here there are two things I find utterly astonishing:
(1) That you seem to think this a good idea, despite that list of problems
Yes, individual apps can CHOOSE to do their own expansion, but that is workable because that expansion-list is segregrated from other parameters.
On 22/12/2022 22:55, Bart wrote:
I expect you didn't like DOS because it doesn't have the dozens of
toys that you came to rely on in Unix, including a built-in C
compiler; what luxury!
I find it useful to have a well-populated toolbox. I am an engineer - finding the right tools for the job, and using them well, is what I do.
DOS gave you a rock to bash things with. Some people, such as
yourself, seem to have been successful at bashing out your own tools
with that rock. That's impressive, but I find it strange how you can be happy with it.
The alternative in DOS and Windows has always been to buy additional
tools that *nix users take for granted. And those tools always have to include /everything/.
So while a Pascal compiler for *nix just needs to
be a Pascal compiler - because there are editors, build systems,
debuggers, libraries, assemblers and linkers already - on DOS/Windows
you had to get Turbo Pascal or Borland Pascal which had everything
included.
(Turbo Pascal for DOS and Win3.1 included "make", by the way
- for well over a decade that was the build tool I used for all my
assembly and C programming on microcontrollers.) And then when you
wanted C, you bought MSVC which included a different editor with a
different setup, a different assembler, a different build tool (called "nmake", and so on. Everything was duplicated but different, everything incompatible, everything a huge waste of the manufacturers time and
effort, and a huge waste of the users' money and time as they had to get familiar with another set of basic tools.
Do I like the fact that *nix has always come with a wide range of general-purpose tools? Yes, I most surely do!
It's because DOS was so sparse that I have few dependencies on it; and
my stuff can build on Linux more easily than Linux programs can build
on Windows. (AIUI, most won't; you need to use CYGWIN or MSYS or WSL,
but then you don't get a bona fide Windows executable that customers
can run directly.)
Programs built with msys2 work fine on any Windows system. You have to include any DLL's you use, but that applies to all programs with all tools.
Then there was the OS - it was crap. Unix was vastly better than CP/M
and the various DOS's.
But IBM was not involved in Unix at that time,
and did not want others to control the software on their machines. (They thought they could control Microsoft.)
Or compare it to other machines, such as the BBC Micro. It had the OS
in ROM, making it far simpler and more reliable. It had a good
programming language in ROM. (BASIC, but one of the best variants.)
This meant new software could be written quickly and easily in a high
level language, instead of assembly (as was the norm for the PC in the
early days). It had an OS that was expandable - it supported pluggable
file systems that were barely imagined at the time the OS was designed.
It was a tenth of the price of the PC.
Of course the BBC Micro wasn't perfect either, and had limitations
compared to the PC - not surprising, given the price difference. The
6502 was not a powerful processor.
But imagine what we could have had with a computer using a 68000,
running a version of Unix, combining the design innovation,
user-friendliness and forward thinking of Acorn and the business
know-how of IBM? It would have been achievable at lower cost than the
IBM PC, and /so/ much better.
As it was, by the mid-eighties there were home computers with usability, graphics and user interfaces that were not seen in the PC world for a decade. There were machines that were cheaper than the PC's of the time
and could /emulate/ PC's at near full-speed. The PC world was far
behind in its hardware, OS and basic software. But the IBM PC and MSDOS
won out because the other machines were not compatible with the IBM PC
and MSDOS.
I used Unix systems at university in the early 1990's, and by $DEITY it
was a /huge/ step backwards when I had to move to Windows.
The 8088/86/286 had some disappointing limitations, which were fixed
with the 80386.
It's a pity MS didn't catch up with proper 32-bit support until AMD were already working on 64-bit versions.
On the business and marketing side, there's no doubt that MS in
particular outclassed everyone else. They innovated the idea of
criminal action as a viable business tactic - use whatever illegal means
you like to ensure competitors go bankrupt before they manage to sue
you, and by the time the case gets to the courts the fines will be
negligible compared to your profit. Even IBM was trapped by them.
But yes, compatibility and market share was key - Windows and PC's were popular because there was lots of hardware and software that worked with them, and there was lots of hardware and software for them because they
were popular. They were technically shite,
Which has been excellent. Until they chose not to support 16-bit
binaries under 64-bit Windows.
I believe you can run Wine on Windows, and then you could run 16-bit binaries. But you might have to run Wine under Cygwin or something -
it's not something I have tried.
But I don't understand how you can take personal offence when I talk
about operating systems, or how you end up thinking it was a
criticism of you or your language.
I get annoyed when people openly diss Windows, or MSDOS, simply for
not being Linux.
I diss Windows or DOS because it deserves it. Linux was not conceived
when I realised DOS was crap compared to the alternatives. (You always
seem to have such trouble distinguishing Linux and Unix.)
So much negativity here.
Bart <bc@freeuk.com> wrote:
That will be up to individual programs whether they accept wildcards for
filenames, and what they do about them. If the input is "*", what kinds
of application would be dealing with an ill-matched collection of files
including all sorts of junks that happens to be lying around?
Yesterday I used several times the following:
du -s *
'man du' will tell you want is does. And sometimes I use the
(in)famous:
rm -rf *
Do not try this if you do not know what it is doing!
It would be very specific. BTW if I do this under WSL:
vim *.c
Then I was disappointed that I didn't get hundreds of edit windows for
all those files. So even under Linux, sometimes expansion doesn't
happen. (What magic does vim use to get the OS to see sense?)
I suspect that you incorrecty interpreted your observation.
Usually the last thing you want is for the OS (or whatever is
responsible for expanding those command line params before they get to
the app) is to just expand EVERYTHING willy-nilly:
Speak about yourself. If application needs a list of files I want
this list to be expanded.
I am under impression that you miss important fact: Unix was designed
as a _system_. Programs expect system conventions and work with them,
not against them. One convention is that there are few dozens (myriad
in your language) small programs that are supposed to work together.
Shell works as a glue that combines them together. Shell+utilities
form a programming language, crappy as programming language, but
quite useful. In particular, ability to transform/crate command
line via programming means allows automating a lot of tasks.
Just more on my point of view: I started to use DOS around 1988
(I was introduced to computers on mainframes and I had ZX
Spectrum earlier). My first practical contact with Unix was in
1990. It took me some time to understand how Unix works, but once
I "got it" I was able easily to do things on Unix that would be
hard (or require much more work) on DOS. By 1993 I was mostly
using Unix (more precisely, at that time I switched from 386BSD
Unix to Linux).
Coming back to Unix: it works for me. DOS in comparison felt
crappy. Compared to 1993 Windows has improved, but for me
this does not change much, I saw nothing that would be
better for _me_ than what I have in Linux. Now, if you want to
improve, one can think of many ways of doing thing better than on
Unix. Trouble is to that real-world design will have compromises.
One looses some possibilites to have another ones. You either
does not understand Unix or at least pretend to not understand.
If you do not understand Unix, then you do not qualified to judge
it. It looks that you do not know what you loose by choosing
different design.
BTW: I did spent some time thinking of better command line than
Unix. Some my ideas were quite different. But none were borrowed
from DOS.
rm -rf *
Do not try this if you do not know what it is doing!
On 2022-12-22 16:09, Andy Walker wrote:
????You [and probably Dmitry] seem to have a very weird idea of what
Unix /is/.
I don't know about Bart. As for me, I started with PDP-11 UNIX and
continued with m68k UNIX Sys V. Both were utter garbage in every
possible aspect inferior to any competing system with worst C compilers
I ever seen.
Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
On 2022-12-22 16:09, Andy Walker wrote:
????You [and probably Dmitry] seem to have a very weird idea of what
Unix /is/.
I don't know about Bart. As for me, I started with PDP-11 UNIX and
continued with m68k UNIX Sys V. Both were utter garbage in every
possible aspect inferior to any competing system with worst C compilers
I ever seen.
Can you name those superior competing systems?
One of the way to illustrate the beauty of UNIX "ideas" is this:
$ echo "" > -i
Now try to "more" or remove it (:-))
On 24/12/2022 00:46, Bart wrote:
On 23/12/2022 15:38, David Brown wrote:
But tell me again why a 'linker', of all things, should be part of a
consumer product mostly aimed at people doing things that are nothing
to do with building software. Why give it such special dispensation?
It is convenient to have on the system. Programs can rely on it being there.
On 23/12/2022 15:38, David Brown wrote:
On 22/12/2022 22:55, Bart wrote:
I expect you didn't like DOS because it doesn't have the dozens of
toys that you came to rely on in Unix, including a built-in C
compiler; what luxury!
I find it useful to have a well-populated toolbox. I am an engineer -
finding the right tools for the job, and using them well, is what I
do. DOS gave you a rock to bash things with. Some people, such as
yourself, seem to have been successful at bashing out your own tools
with that rock. That's impressive, but I find it strange how you can
be happy with it.
You seem fixated on DOS. My early coding was done on DEC and ICL OSes,
then no OS at all, then CP/M (or our clone of it).
The tools provided, when they were provided, were always spartan:
editor, compiler, linker, assembler. That's nothing new.
The alternative in DOS and Windows has always been to buy additional
tools that *nix users take for granted. And those tools always have
to include /everything/.
'Everything' is good. Remember those endless of discussions on clc about
what exactly constituted a C compiler? Because this new-fangled 'gcc'
didn't come with batteries included, like header files, assembler or
linker.
A bad mistake on Windows where those utilities are not OS-provided.
But tell me again why a 'linker', of all things, should be part of a
consumer product mostly aimed at people doing things that are nothing to
do with building software. Why give it such special dispensation?
So while a Pascal compiler for *nix just needs to be a Pascal
compiler - because there are editors, build systems, debuggers,
libraries, assemblers and linkers already - on DOS/Windows you had to
get Turbo Pascal or Borland Pascal which had everything included.
You can get bare compilers on Windows too.
(Turbo Pascal for DOS and Win3.1 included "make", by the way - for
well over a decade that was the build tool I used for all my assembly
and C programming on microcontrollers.) And then when you wanted C,
you bought MSVC which included a different editor with a different
setup, a different assembler, a different build tool (called "nmake",
and so on. Everything was duplicated but different, everything
incompatible, everything a huge waste of the manufacturers time and
effort, and a huge waste of the users' money and time as they had to
get familiar with another set of basic tools.
Nothing stopped anybody from marketing a standalone assembler or linker
that could be used with third party compilers. These are not complicated programs (a workable linker is only 50KB).
I can't answer that. Unless that assembler used 'gas' syntax then I
would write my own too.
Do I like the fact that *nix has always come with a wide range of
general-purpose tools? Yes, I most surely do!
What did that do for companies wanting to develop and sell their own compilers and tools?
Or compare it to other machines, such as the BBC Micro. It had the OS
in ROM, making it far simpler and more reliable. It had a good
programming language in ROM. (BASIC, but one of the best variants.)
This meant new software could be written quickly and easily in a high
level language, instead of assembly (as was the norm for the PC in the
early days). It had an OS that was expandable - it supported
pluggable file systems that were barely imagined at the time the OS
was designed. It was a tenth of the price of the PC.
It used a 6502. I'd argue it was better designed than any Sinclair
product, with a proper keyboard, but it was still in that class of machine.
BTW this is the kind of machine my company were selling:
https://nosher.net/archives/computers/pcw_1982_12_006a
(My first redesign task was adding the bitmapped graphics on the display.)
Of course the BBC Micro wasn't perfect either, and had limitations
compared to the PC - not surprising, given the price difference. The
6502 was not a powerful processor.
As I said...
More business-oriented 8-bit systems were based on the Z80, such as the
PCW 8256, with CP/M 3. (My first commercial graphical application was
for that machine IIRC.)
So you don't rate its OS - so what? All customers needed were the most mundane things. It was a marketed as a word processor after all!
But imagine what we could have had with a computer using a 68000,
running a version of Unix, combining the design innovation,
user-friendliness and forward thinking of Acorn and the business
know-how of IBM? It would have been achievable at lower cost than the
IBM PC, and /so/ much better.
As it was, by the mid-eighties there were home computers with
usability, graphics and user interfaces that were not seen in the PC
world for a decade. There were machines that were cheaper than the
PC's of the time and could /emulate/ PC's at near full-speed. The PC
world was far behind in its hardware, OS and basic software. But the
IBM PC and MSDOS won out because the other machines were not
compatible with the IBM PC and MSDOS.
That's true. I was playing with 24-bit RGB graphics for my private
designs about a decade before it became mainstream on PCs.
But where were the Unix alternatives that people could buy from PC
World? Sure there had been colour graphics in computers for years but
I'm talking about consumer PCs.
I used Unix systems at university in the early 1990's, and by $DEITY
it was a /huge/ step backwards when I had to move to Windows.
I went from a £500,000 (in mid-70s money) mainframe at college, running
TOPS 20 I think, to my own £100 Z80 machine with no OS on it at all, and
no disk drives either.
I'd say /that/ was a huge step backwards! Perhaps you can appreciate why
I'm not that bothered.
The 8088/86/286 had some disappointing limitations, which were fixed
with the 80386.
It's a pity MS didn't catch up with proper 32-bit support until AMD
were already working on 64-bit versions.
It wasn't so critical with the 80386. Programs could run in 16-bit mode
under a 16-bit OS, and use 32-bit operations, registers and address modes.
On the business and marketing side, there's no doubt that MS in
particular outclassed everyone else. They innovated the idea of
criminal action as a viable business tactic - use whatever illegal
means you like to ensure competitors go bankrupt before they manage to
sue you, and by the time the case gets to the courts the fines will be
negligible compared to your profit. Even IBM was trapped by them.
I never got interested in that side; I was always working to deadlines!
But what exactly was the point of Linux? What exactly was wrong with Unix?
But yes, compatibility and market share was key - Windows and PC's
were popular because there was lots of hardware and software that
worked with them, and there was lots of hardware and software for them
because they were popular. They were technically shite,
/Every/ software and hardware product for Windows was shite? Because
you're looked at every one and given your completely unbiased opinion!
Which has been excellent. Until they chose not to support 16-bit
binaries under 64-bit Windows.
I believe you can run Wine on Windows, and then you could run 16-bit
binaries. But you might have to run Wine under Cygwin or something -
it's not something I have tried.
(I gave this 10 minutes but it lead nowwhere. Except it involved an
extra 500MB to install stuff that didn't work, but when I purged it, it
only recovered 0.2MB.
Hmmm.. have I mentioned the advantages of a piece of software that comes
and runs as a single executable file? Either its there or not there.
There's nowhere for it to hide!)
But I don't understand how you can take personal offence when I talk
about operating systems, or how you end up thinking it was a
criticism of you or your language.
I get annoyed when people openly diss Windows, or MSDOS, simply for
not being Linux.
I diss Windows or DOS because it deserves it. Linux was not conceived
when I realised DOS was crap compared to the alternatives. (You
always seem to have such trouble distinguishing Linux and Unix.)
Understandably. What exactly /is/ the difference? And what are the differences between the myriad different versions of Linux even for the
same platform?
Apparently having more than one assembler or linker on a platform is a disaster.
But have 100 different versions of the same OS, that's
perfectly fine!
I like all these contradictions.
On 2022-12-27 13:24, David Brown wrote:
On 24/12/2022 00:46, Bart wrote:
On 23/12/2022 15:38, David Brown wrote:
But tell me again why a 'linker', of all things, should be part of a
consumer product mostly aimed at people doing things that are nothing
to do with building software. Why give it such special dispensation?
It is convenient to have on the system. Programs can rely on it being
there.
I have an impression that you guys confuse linker with loader. Programs (applications) do not need linker.
On 18/12/2022 13:05, David Brown wrote:
There are standards for that.? A text-based file can have a shebang
comment ("#! /usr/bin/bash", or similar) to let the shell know what interpreter to use.? This lets you distinguish between "python2" and "python3", for example, which is a big improvement over Windows-style
file associations that can only handle one interpreter for each file
type.
That is invasive. And taking something that is really an attribute of a
file name, in having it not only inside the file, but requiring the file
to be opened and read to find out.
(Presumably every language that runs on Linux needs to accept '#' as a
line comment? And you need to build it in to every one of 10,000 source
files the direct location of the Python2 or Python3 installation on that machine? Is that portable across OSes? But I expect it's smarter than that.)
You do realise that gcc can handle some 30-odd different file types?
That doesn't change the fact that probably 99% of the time I run gcc, it
is with the name of a .c source file. And 99.9% of the times when I
invoke it on prog.c as the first or only file to create an executable,
then I want to create prog.exe.
So its behaviour is unhelpful. After the 10,000th time you have to type
.c, or backspace over .c to get at the name itself to modify, it becomes tedious.
Now it's not that hard to write a wrapper script or program on top of gcc.exe, but if it isn't hard, why doesn't it just do that?
It's not a simple C compiler that assumes everything it is given is a C file.
As I said, that is not helpful for me. Also, how many file types does
'as' accept? As that also requires the full extension,
and also,
bizarrely, generates `a.out` as the object file name.
Here's something funny: take hello.c and rename to 'hello', with no extension. If I try and compile it:
gcc hello
it says: hello: file not recognised: file format not recognised. Trying
'gcc hello.' is worse: it can't see the file at all.
So first, on Linux, where file extensions are supposed to be optional,
gcc can't cope with a missing .c extension; you have to provide extra
info. Second, on Linux, "hello" is a distinct file from "hello.".
With bcc, I just have to type "bcc hello." to make it work. A trailing
dot means an empty extension.
On 22/12/2022 15:09, Andy Walker wrote:
You complain
that you have to write "./hello" rather than just "hello";? but that's
because "." is not in your "$PATH", which is set by you, not because
Unix/Linux insists on extra verbiage.? If you need further help, just
ask.? But I'd expect you to be able to work it out rather than wring
your hands and flap around helplessly [or blame Unix for it].
So lots of workarounds to be able to do what DOS, maligned as it was,
did effortlessly.
It seems that nobody mentioned this: not having '.' in PATH is
relatively recent trend.
So automate things.
rename file and look how it affects compilations, then you may
do a lot of command line editing. In normal use the same
Makefile with can be used for tens or hundreds of edits to
source files.
Some folks use compile commands in editors. That works nicely
because rules are simple.
Now it's not that hard to write a wrapper script or program on top of
gcc.exe, but if it isn't hard, why doesn't it just do that?
You miss important point: gcc gives you a lot of possibilities.
Simple wrapper which substitutes some defaults would make
using non-default values harder or impossible.
If you want
to have all functionality of gcc you will end up with complicated
command line.
It's not a simple C compiler that assumes everything it is given is a C
file.
As I said, that is not helpful for me. Also, how many file types does
'as' accept? As that also requires the full extension,
AFAICS as accepts any extention. I can name my assember file
'ss.m' and it works fine.
You are determined not to learn
parties: in Linux file name is just string of characters. Dot is
as valid character in a name as any other.
I privately coined the term 'loader' in the 1980s for a program that
combined multiple object files, from independently compiled source
modules of a program, into a single program binary (eg. a .com file).
It was also pretty much what a linker did, yet a linker was a far more complicated program that also took much longer. What exactly do linkers
do? I'm still not really sure!
Anyway, I no longer have a need to combine object files (there are no
object files). But there are dynamic fix-ups needed, which the OS EXE
loader will do, between an EXE and its imported DLLs.
On 22/12/2022 15:09, Andy Walker wrote:
You complain
that you have to write "./hello" rather than just "hello";? but that's because "." is not in your "$PATH", which is set by you, not because Unix/Linux insists on extra verbiage.? If you need further help, just
ask.? But I'd expect you to be able to work it out rather than wring
your hands and flap around helplessly [or blame Unix for it].
So lots of workarounds to be able to do what DOS, maligned as it was,
did effortlessly.
You two aren't going to be happy until my language is a clone of C, with tools that work exactly the same way they do on Unix. But then you're
going to say, what's the point?
So automate things.
Isn't gcc already an automated wrapper around compiler, assembler and
linker?
Of course, if your hobby is to continously
rename file and look how it affects compilations, then you may
do a lot of command line editing. In normal use the same
Makefile with can be used for tens or hundreds of edits to
source files.
Some folks use compile commands in editors. That works nicely
because rules are simple.
Now it's not that hard to write a wrapper script or program on top of
gcc.exe, but if it isn't hard, why doesn't it just do that?
You miss important point: gcc gives you a lot of possibilities.
Simple wrapper which substitutes some defaults would make
using non-default values harder or impossible.
Not on Windows. Clearly, Linux /would/ make some things impossible,
because there are no rules so anything goes.
The rules for my BCC compiler inputs are:
Input Assumes file
file.c file.c
file.ext file.ext
file file.c
file. file # use "file." when file has no extension
This is not possible with Unix, since "file." either ends up as "file",
or stays as "file." You can only refer to "file" or "file.", but not both.
So a silly decision with Unix, which really buys you very little, means having to type .c extensions on inputs to C files, for eternity.
If you want
to have all functionality of gcc you will end up with complicated
command line.
It's not a simple C compiler that assumes everything it is given is a C >>> file.
As I said, that is not helpful for me. Also, how many file types does
'as' accept? As that also requires the full extension,
AFAICS as accepts any extention. I can name my assember file
'ss.m' and it works fine.
But you need an extension. Give it a null extension then resulting executable, if this is the only module, will clash.
My point however was the the reason gcc needs an explicit extension was
the number of possible input file types. How many /different/ file types
does 'as' work with?
I write my command-line utilities both to be easy to use when manually invoked, and for invoking from scripts.
My experience of Unix utilities is that they do nothing of the sort;
they have no provision for user-friendliness whatsoever.
You are determined not to learn
You also seem reluctant to learn how non-Unix systems might work, or acknowledge that they could be better and more user-friendly.
, but for possible benefits of third
parties: in Linux file name is just string of characters. Dot is
as valid character in a name as any other.
Well, that's wrong. It may have sounded a good idea at one time: accept
ANY non-space characters as the name of a file.
But that allows for a
lot of completely daft names, while disallowing some sensible practices.
There is no structure at all, no possibility for common sense.
With floating point numbers, 1234 is the same value as 1234. while
1234.. is an error, but they are all legal and distinct filenames under
Unix.
Under Windows, 1234 1234. 1234... all represent the same "1234" file.
While 123,456 are two files "123" and "456"; finally, some rules!
[...] You complainSo lots of workarounds to be able to do what DOS, maligned as it was,
that you have to write "./hello" rather than just "hello"; but that's
because "." is not in your "$PATH", which is set by you, not because
Unix/Linux insists on extra verbiage. If you need further help, just
ask. But I'd expect you to be able to work it out rather than wring
your hands and flap around helplessly [or blame Unix for it].
did effortlessly.
Don't forget it is not just me personally who would have trouble. For
over a decade, I was supplying programs that users would have to
launch from their DOS systems, or on 8-bit systems before that.
So every one of 1000 users would have to be told how to fix that "."
problem?
Fortunately, nobody really used Unix back then (Linux was
not yet ready), at least among our likely customers who were just
ordinary people.
Fortunate also that with case-sensivitivity in the shell program and
file system, it would have created a lot more customer support
headaches.
But you can write your own almost trivially;Sure. I also asked, if it is so trivial, why don't programs do that
it's a "one-line" shell script
anyway?
Learn something from DOS at least which is user
friendliness.
because C and Linux have taken over the world [...].Really? According to
Notice that most user-facing interfaces tend to be case-insensitive?
So, nobody here thinks that doing 'mm -ma appl' to produce a one-file
appl.ma file representing /the entire application/, that can be
trivially compiled remotely using 'mm appl.ma', is a great idea?
Well, have a look at the A68G source bundle for example: [...].
Like so many, this application starts with a
'configure' script, although only 9500 lines this time. So I can't
build it on normal Windows.
But typing 'make' again still took 1.4 seconds even with nothing to
do.
Then I looked inside the makefile: it was an auto-generated one with
nearly 3000 lines of crap inside - no wonder it took a second and a
half to do nothing!
In article <tof7ol$ovb$1@gioia.aioe.org>, <antispam@math.uni.wroc.pl> wrote:
Bart <bc@freeuk.com> wrote:
On 22/12/2022 15:09, Andy Walker wrote:
You complain
that you have to write "./hello" rather than just "hello";? but
that's because "." is not in your "$PATH", which is set by you,
not because Unix/Linux insists on extra verbiage.? If you need
further help, just ask.? But I'd expect you to be able to work
it out rather than wring your hands and flap around helplessly
[or blame Unix for it].
So lots of workarounds to be able to do what DOS, maligned as it
was, did effortlessly.
It seems that nobody mentioned this: not having '.' in PATH is
relatively recent trend.
Define "recent": I haven't included `.` in my $PATH for
30 or so years now. :-)
Bart <bc@freeuk.com> wrote:
So automate things.
Isn't gcc already an automated wrapper around compiler, assembler and
linker?
You miss principle of modularity: gcc contains bulk of code (I mean
the wrapper, it is quite large given that all what it is doing
is handling command line). Your own code can provide fixed
values (so that you do not need to retype them) and more complex
behaviours (which would be too special to have as gcc options).
In fact, 'make' was designed to be tool for "directing compilation",
it handles things at larger scale than gcc.
To put is differently: gcc and make provide mechanizms. It is
to you to specify policy.
BTW: there are now several competitors to make. One is 'cmake'.
Of course, if your hobby is to continously
rename file and look how it affects compilations, then you may
do a lot of command line editing. In normal use the same
Makefile with can be used for tens or hundreds of edits to
source files.
Some folks use compile commands in editors. That works nicely
because rules are simple.
Now it's not that hard to write a wrapper script or program on top of
gcc.exe, but if it isn't hard, why doesn't it just do that?
You miss important point: gcc gives you a lot of possibilities.
Simple wrapper which substitutes some defaults would make
using non-default values harder or impossible.
Not on Windows. Clearly, Linux /would/ make some things impossible,
because there are no rules so anything goes.
What I wrote really have nothing to with operating system, this
is very general principle.
The rules for my BCC compiler inputs are:
Input Assumes file
file.c file.c
file.ext file.ext
file file.c
file. file # use "file." when file has no extension
This is not possible with Unix, since "file." either ends up as "file",
or stays as "file." You can only refer to "file" or "file.", but not both.
You can implement your rules on Unix. Of course, one can ask if the
rules are useful. As written above your rules make it impossible to
access file named "file." (it will be mangled to "file"). And you
get quite unintuitive behaviour for "file".
So a silly decision with Unix, which really buys you very little, means
having to type .c extensions on inputs to C files, for eternity.
Nobody forces you to have extention on files.
And do not exagerate,
two characters extra from time to time do not make much difference.
If you want
to have all functionality of gcc you will end up with complicated
command line.
It's not a simple C compiler that assumes everything it is given is a C >>>>> file.
As I said, that is not helpful for me. Also, how many file types does
'as' accept? As that also requires the full extension,
AFAICS as accepts any extention. I can name my assember file
'ss.m' and it works fine.
But you need an extension. Give it a null extension then resulting
executable, if this is the only module, will clash.
as ss
will produce 'a.out' (as you know). If there is no a.out there will
be no clash, otherwise you need to specify output file, like:
as ss -o ss.m
or
as ss -o tt
Note: as produces object file (it does not link). For automatic
linking use gcc.
My point however was the the reason gcc needs an explicit extension was
the number of possible input file types. How many /different/ file types
does 'as' work with?
as have no notion of "file type". as takes stream of bytes and turns
it into object file (different thing from an executable!). Stream
of bytes may come from file, but in typical use (when as is called by
gcc) as gets its input from a pipe.
I write my command-line utilities both to be easy to use when manually
invoked, and for invoking from scripts.
My experience of Unix utilities is that they do nothing of the sort;
they have no provision for user-friendliness whatsoever.
Old saying (possibly mangled): "Unix is friendly, just not everybody
is its friend".
You are determined not to learn
You also seem reluctant to learn how non-Unix systems might work, or
acknowledge that they could be better and more user-friendly.
"might work" is almost meaningless. By design Unix allows a lot
of flexibility so it "might work" in quite different way.
[...] And letter
case must be spot-on too: so was that file oneTwo or OneTwo or
Onetwo? And commands must be spot-on as well:
you type 'ls OneTwo'
then you look up and realise Caps-lock was on and you typed 'LS
oNEtWO'; urggh! Start again..
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 08:19:48 |
| Calls: | 10,387 |
| Calls today: | 2 |
| Files: | 14,058 |
| Messages: | 6,416,656 |
