h a l f b a k e r yViva los semi-panaderos!
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
Hmmmm...
usually we write normal C functions like this
out = some_func( input1, input2 );
Which usually implies fixed set of inputs and one result
output.
But what if you want more than one output? Usually that is
done
via
some_func( input1, &out2 );
But when I draw mental graph
of my programs its more like
---- Data input --->[ Black Box (param1, param2) ] --- Data
output --->
So in C, when dealing with data flows... I sorta try to keep to
that model via:
void func_name ( const int input, const int param, int
*output);
But sometimes i want to avoid making new variables for ram
savings... so
void func_name ( const int param, int *input_and_output);
-----
So if we have some way of expressing the concept of "data
input"
"const parameters" and "data output"... that would be cool.
int VarIn=1, Varout=0;
(VarIn)
|
|
V
funcA( param1, param2, param3 )
|
|
V
funcB( param1, param2, param3 )
|
|
V
(VarOut)
Obviously above example sucks, but it might get the point
across
of maybe thinking of a way to have a more flowcharty way of
representing programming logic.
Skov
http://skov.software/en/
Flowchart-y language [Cuit_au_Four, Dec 28 2016]
Viskell
https://github.com/viskell/viskell
Visual IDE for Haskell-like language [Cuit_au_Four, Dec 28 2016]
Literate programming
https://en.wikipedi...iterate_programming
by Donald Knuth [notexactly, Dec 30 2016]
[link]
|
| |
You can always declare some_func() as returning a pointer to a structure - that's simple and elegant and removes the need for declaring GLOBAL STATICs, which are clumsy and eat memory. |
|
| |
BCPL might be a better starting point than C, if you want to define your meta-language as a Chomsky syntax-free grammar. |
|
| |
// But what if you want more than one output? |
|
| |
Then return either a tuple or return a polymorphic type, if your language supports these things. If you're working in a C-like language, return a pointer to structure that has a type field. A function can only have one range. If your function returns apples for some inputs and oranges for other inputs, then its range is the union of apples and oranges (and possibly the null fruit). If it always returns one apple and one orange, then its range is the Cartesian product of apples and oranges. |
|
| |
// return a pointer to structure that has a type field. // |
|
| |
We said that already. <points at first anno> |
|
| |
They're pretty tasteless ... |
|
| |
yea i am aware of passing structs. just somehow not really
satisfied about it. |
|
| |
so... you want a variable to have more than one name ? easy enough in cobol ("rename"). C, I imagine you'd do something a bit more awkwardy with pointers or structs. still not complicated, though. |
|
| |
> if idea = other: [general] / then CATEGORY SELECT invalid ... |
|
| |
The idea's more about a way of describing data flow paths, rather
than the actual mechanism. |
|
| |
In the MS world, Workflow Foundation lets you do this sort of thing ... so long as you don't mind race conditions in the build process, and suchlike MS-y features. |
|
| |
// ErrorEnum = func( in a, in b, in c, out x, out y, out z) // |
|
| |
In Blue Book C that only works if out x, out y, out z are GLOBAL STATIC, or passed as pointers to variables within the calling function. You can't dynamically return an rvalue via a function call argument. |
|
| |
Besides, unless the variables are big structures, arrays, or strings, why worry about RAM usage ? Is this an embedded application - if so, is C the right tool for the job ? |
|
| |
Hand-coded assembler will beat the best optimising compiler every time. Just enjoy the debugging ... |
|
| |
This reminds me of two things: the function definition
syntax used in Haskell and similar functional languages,
and literate programming [link]. |
|
| |
Eh, you really gotta understand that cost is still a factor in
getting more ram in embedded programming. |
|
| |
Also perhaps rust has an interesting way of dealing with
"input
output" declaration, via ownership transfer. Because the
issue
with C, is if you create a working variable, but it gets
scoped
out when you return the pointer to it (upon end of that
function). |
|
| |
(Though admittedly transfer of ownership doesn't enforce
not changing the input in rust). |
|
| |