Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #63005 > unrolled thread

one type less language

Back to article view | Back to comp.lang.c

Contents

  one type less language asetofsymbols@gmail.com - 2015-06-05 22:08 -0700
    Re: one type less language David Kleinecke <dkleinecke@gmail.com> - 2015-06-06 09:35 -0700
    Re: one type less language Richard Damon <Richard@Damon-Family.org> - 2015-06-06 13:10 -0400
      Re: one type less language Les Cargill <lcargill99@comcast.com> - 2015-06-06 13:01 -0500
      Re: one type less language Michael Angelo Ravera <maravera@prodigy.net> - 2015-06-07 13:03 -0700
    Re: one type less language Les Cargill <lcargill99@comcast.com> - 2015-06-06 12:55 -0500
    one type less language asetofsymbols@gmail.com - 2015-06-06 12:15 -0700
      Re: one type less language Bartc <bc@freeuk.com> - 2015-06-06 20:23 +0100
      Re: one type less language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-06 20:28 +0100
      Re: one type less language jt@toerring.de (Jens Thoms Toerring) - 2015-06-06 23:21 +0000
        Re: one type less language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-07 09:59 -0700
          Re: one type less language Bartc <bc@freeuk.com> - 2015-06-07 20:20 +0100
            Re: one type less language jt@toerring.de (Jens Thoms Toerring) - 2015-06-08 09:42 +0000
              Re: one type less language Bartc <bc@freeuk.com> - 2015-06-08 11:28 +0100
                Re: one type less language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-06-08 05:10 -0700
                  Re: one type less language Mel <mel@zzzzz.com> - 2015-06-08 15:39 +0300
        Re: one type less language "J. Clarke" <j.clarke.873638@gmail.com> - 2015-09-08 05:23 -0400
          Re: one type less language Robert Wessel <robertwessel2@yahoo.com> - 2015-09-08 10:20 -0500
    Re: one type less language Keith Thompson <kst-u@mib.org> - 2015-06-06 13:56 -0700
      Re: one type less language luser droog <luser.droog@gmail.com> - 2015-06-07 23:20 -0700
        Re: one type less language asetofsymbols@gmail.com - 2015-06-08 02:50 -0700

Page 1 of 2  [1] 2  Next page →

#63005 — one type less language

Yes it is possible to have a language
without types...
Than how easy represent
struct name{
Type1  name;
Type2  name2;
Etc
};
And find the errors in wrong type
operator= call?

[toc] | [next] | [standalone]

#63017

On Friday, June 5, 2015 at 10:08:55 PM UTC-7, asetof...@gmail.com wrote:
> Yes it is possible to have a language
> without types...
> Than how easy represent
> struct name{
> Type1  name;
> Type2  name2;
> Etc
> };
> And find the errors in wrong type
> operator= call?

Basically you just don't allow struct's et al.

The original Basic - a long time ago - was a language without types.
Everything was a floating point number. 

You could do some things in the original Basic - but not much. The
first extension was to add strings. That worked quite well but adding
integers was iresistable and so on.

I suggest sticking with types.

[toc] | [prev] | [next] | [standalone]

#63018

On 6/6/15 1:08 AM, asetofsymbols@gmail.com wrote:
> Yes it is possible to have a language
> without types...
> Than how easy represent
> struct name{
> Type1  name;
> Type2  name2;
> Etc
> };
> And find the errors in wrong type
> operator= call?
>

Isn't it a contradiction of terms to have a "Typeless" language and then 
have a "wrong type" call?

Actually, I am not sure if I know of a language without type (there may 
well be one) but I think you are thinking of languages with run time 
type bindings, i.e. a "variable" doesn't have a predefined type, but can 
at different times hold values of differing types. In such a language, 
yes, the system won't flag putting the "wrong type" into a "variable", 
just as in C the compiler won't flag putting the wrong value (of the 
right type) into a variable, you need to detect this and then look back 
to find out where it came from.

[toc] | [prev] | [next] | [standalone]

#63020

Richard Damon wrote:
> On 6/6/15 1:08 AM, asetofsymbols@gmail.com wrote:
>> Yes it is possible to have a language
>> without types...
>> Than how easy represent
>> struct name{
>> Type1  name;
>> Type2  name2;
>> Etc
>> };
>> And find the errors in wrong type
>> operator= call?
>>
>
> Isn't it a contradiction of terms to have a "Typeless" language and then
> have a "wrong type" call?
>

No; you have to constrain over what domain a value is "wrong" because
of a semantic type mismatch.

> Actually, I am not sure if I know of a language without type (there may
> well be one) but I think you are thinking of languages with run time
> type bindings, i.e. a "variable" doesn't have a predefined type, but can
> at different times hold values of differing types.


Basically.

In Tcl  you can:


% catch {
    set x [ expr Hello + 42.0 ]
    puts "x=<$x>"
} ow
1
% puts "ow=<$ow>"
ow=<invalid bareword "Hello"
in expression "Hello + 42.0";
should be "$Hello" or "{Hello}" or "Hello(...)" or ...>
%


This being said, Tcl is not purely typeless. "Everything
is a string" ( until it isn't ). String is the least restrictive
type and bad conversions are what is flagged.

> In such a language,
> yes, the system won't flag putting the "wrong type" into a "variable",
> just as in C the compiler won't flag putting the wrong value (of the
> right type) into a variable, you need to detect this and then look back
> to find out where it came from.

-- 
Les Cargill

[toc] | [prev] | [next] | [standalone]

#63047

On Saturday, June 6, 2015 at 10:11:04 AM UTC-7, Richard Damon wrote:
> On 6/6/15 1:08 AM, asetofsymbols@gmail.com wrote:
> > Yes it is possible to have a language
> > without types...
> > Than how easy represent
> > struct name{
> > Type1  name;
> > Type2  name2;
> > Etc
> > };
> > And find the errors in wrong type
> > operator= call?
> >
> 
> Isn't it a contradiction of terms to have a "Typeless" language and then 
> have a "wrong type" call?
> 
> Actually, I am not sure if I know of a language without type (there may 
> well be one) but I think you are thinking of languages with run time 
> type bindings, i.e. a "variable" doesn't have a predefined type, but can 
> at different times hold values of differing types. In such a language, 
> yes, the system won't flag putting the "wrong type" into a "variable", 
> just as in C the compiler won't flag putting the wrong value (of the 
> right type) into a variable, you need to detect this and then look back 
> to find out where it came from.

APL at one point allowed complete dynamic typing and had a large number of rules for conforming types that didn't really conform. For instance, you could multiply a 3x4 matrix by a 6x7 and you would get SOMETHING, but probably not necessarily what you had in mind (I think that it would add two columns of zeros to make the original 3x6 before multiplying and you would end up with a 3x7 result, but it has been over 30 years). If I recall, strings that didn't make sense as a number were treated as zero (or was it that each character was treated as a ASCII value).
If I remember right, you could type
2 + "Sunset at noon"
and you would get
Vunset at noon

[toc] | [prev] | [next] | [standalone]

#63019

asetofsymbols@gmail.com wrote:
> Yes it is possible to have a language
> without types...
> Than how easy represent
> struct name{
> Type1  name;
> Type2  name2;
> Etc
> };
> And find the errors in wrong type
> operator= call?
>


Tcl is basically typeless. I say "basically" because
obviously, " set x [ expr Hello + 43.5 ]" is nonsense
( and will be flagged as such ).

You can use Tcl arrays as structs.

array set name { name "Bob" name2 "Ted" }

puts $name(name)
Bob

You can have arrays of structs by adding "columns" to the indices:

array set name { name,1 "Bob" name2,1 "Ted" name,2 "Fred" name2,2 
"George" }

-- 
Les Cargill

[toc] | [prev] | [next] | [standalone]

#63023

I imagine something as
a="1234asdfv"
b=1.564
c={1,2,3}{4,5,6}
a is a string
b is a number 
c is a 2x3 matrix
So if now I write
b=c
Than b is the matrix 
the same of c
And the memory store the value 1.564
is free.
This is like maple V and other math
language existing I saw in university.
One miss the original type when
there is one operator= 

 is it better a type centric language as C, or C++ or better 
these "type free" languages?

[toc] | [prev] | [next] | [standalone]

#63024

On 06/06/2015 20:15, asetofsymbols@gmail.com wrote:
> I imagine something as
> a="1234asdfv"
> b=1.564
> c={1,2,3}{4,5,6}
> a is a string
> b is a number
> c is a 2x3 matrix
> So if now I write
> b=c
> Than b is the matrix
> the same of c
> And the memory store the value 1.564
> is free.
> This is like maple V and other math
> language existing I saw in university.
> One miss the original type when
> there is one operator=
>
>   is it better a type centric language as C, or C++ or better
> these "type free" languages?

Most dynamic or scripting languages work like that.

They're OK, but if you need something fast, or to implement one of those 
languages, or you have a specific binary interface to talk to, then a 
statically-typed language can be more practical.

You can use more than one language however.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#63025

asetofsymbols@gmail.com writes:

> I imagine something as
> a="1234asdfv"
> b=1.564
> c={1,2,3}{4,5,6}
> a is a string
> b is a number 
> c is a 2x3 matrix
> So if now I write
> b=c
> Than b is the matrix 
> the same of c
> And the memory store the value 1.564
> is free.
> This is like maple V and other math
> language existing I saw in university.
> One miss the original type when
> there is one operator= 
>
>  is it better a type centric language as C, or C++ or better 
> these "type free" languages?

The usual term for this is dynamic typing.  All the "things" in your
example have types, they are just not static (i.e. unchanging) during
the execution of the program.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#63032

asetofsymbols@gmail.com wrote:
> I imagine something as
> a="1234asdfv"
> b=1.564
> c={1,2,3}{4,5,6}
> a is a string
> b is a number 
> c is a 2x3 matrix
> So if now I write
> b=c
> Than b is the matrix 
> the same of c
> And the memory store the value 1.564
> is free.
> This is like maple V and other math
> language existing I saw in university.
> One miss the original type when
> there is one operator= 

>  is it better a type centric language as C, or C++ or better 
> these "type free" languages?

There are lots of languages that don't care much about types,
Python is probably one of the most commonly used at the moment.
But, while a more-or-less type-agnostic language can be very
nice for rapid prototyping, it has also its disadvantages:
not having to define new variables or "cast" in assignments,
it allows for bugs that, in strongly-typed language would
have been caught at some stage (either by the compiler or
the interpreter). So there have been diverging developments
in the last decades. On the one hand, you have (mostly inter-
preted) languages, that don't care too much about types, and
which are mostly well-suited for fast development (and, also,
for use by amateurs that can't be expected to understand the
fine points of types) and languages (like e.g. ADA) that go
into the exact opposite direction and are meant for mission-
critical programs, where a single bug could kill lots of people
(or cost millions) - so making it "harder" to write (buggy)
programs is a huge benefit. C is something in between these
two extremes.

Being a physicist by training and often dealing with data from
acquiring and valuating data from experiments I'd sometimes love
to have an even stronger-typed language that deals with units
automatically (or would throw some kind of exception if, for
example, the result of a multiplication of a voltage and a
curent would be attempted to be stored in a variable that had
not been defined as usable for a power only;-) Having different
units converted automatically (e.g. from pounds to kg or feet
to meters etc.) would be even better - that may have avoided
losing an extremely expensive and irreplaceable spacecraft on
Mars some years ago...
                            Regards, Jens
-- 
  \   Jens Thoms Toerring  ___      jt@toerring.de
   \__________________________      http://toerring.de

[toc] | [prev] | [next] | [standalone]

#63041

On Sunday, June 7, 2015 at 12:21:46 AM UTC+1, Jens Thoms Toerring wrote:
> 
> There are lots of languages that don't care much about types,
> Python is probably one of the most commonly used at the moment.
> But, while a more-or-less type-agnostic language can be very
> nice for rapid prototyping, it has also its disadvantages:
> not having to define new variables or "cast" in assignments,
> it allows for bugs that, in strongly-typed language would
> have been caught at some stage (either by the compiler or
> the interpreter).
>
The motive is to make the script interpreter easier to write.
You just bung in a hash table to allow indexing of dynamic type
elements by string identifier, and you don't care if "name"
returns a string, a structure with title, forename and surname
members, or a function that sets a name. 

[toc] | [prev] | [next] | [standalone]

#63045

On 07/06/2015 17:59, Malcolm McLean wrote:
> On Sunday, June 7, 2015 at 12:21:46 AM UTC+1, Jens Thoms Toerring wrote:
>>
>> There are lots of languages that don't care much about types,
>> Python is probably one of the most commonly used at the moment.
>> But, while a more-or-less type-agnostic language can be very
>> nice for rapid prototyping, it has also its disadvantages:
>> not having to define new variables or "cast" in assignments,
>> it allows for bugs that, in strongly-typed language would
>> have been caught at some stage (either by the compiler or
>> the interpreter).
>>
> The motive is to make the script interpreter easier to write.
> You just bung in a hash table to allow indexing of dynamic type
> elements by string identifier, and you don't care if "name"
> returns a string, a structure with title, forename and surname
> members, or a function that sets a name.

Actually, it makes it a bit harder to write, and the bytecode compiler, 
if there is one, a bit easier. But writing source code becomes quicker 
and easier too, which is the advantage.

The interpreter still needs to do type dispatching at runtime (you do 
need to care when about to multiply a list by a string for example), 
unlike one for a language with static types.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#63058

Bartc <bc@freeuk.com> wrote:
> On 07/06/2015 17:59, Malcolm McLean wrote:
> > On Sunday, June 7, 2015 at 12:21:46 AM UTC+1, Jens Thoms Toerring wrote:
> >>
> >> There are lots of languages that don't care much about types,
> >> Python is probably one of the most commonly used at the moment.
> >> But, while a more-or-less type-agnostic language can be very
> >> nice for rapid prototyping, it has also its disadvantages:
> >> not having to define new variables or "cast" in assignments,
> >> it allows for bugs that, in strongly-typed language would
> >> have been caught at some stage (either by the compiler or
> >> the interpreter).
> >>
> > The motive is to make the script interpreter easier to write.
> > You just bung in a hash table to allow indexing of dynamic type
> > elements by string identifier, and you don't care if "name"
> > returns a string, a structure with title, forename and surname
> > members, or a function that sets a name.

> Actually, it makes it a bit harder to write, and the bytecode compiler, 
> if there is one, a bit easier. But writing source code becomes quicker 
> and easier too, which is the advantage.

> The interpreter still needs to do type dispatching at runtime (you do 
> need to care when about to multiply a list by a string for example), 
> unlike one for a language with static types.

But the interpreter must follow certain rules. And some-
times it follows different rules from what you might have
expected. For example, in Perl you might attempt to ado

$a  = ' 2.3 ';   # that's a string, isn't it?
$a += '   2 ';   # this appends another string to it, doesn't it?
print "$a\n";    # guess what this will print...

Of course, this isn't a string concatenation (since in Perl
you'd have to use the '.' operator for that). But it's also
not a syntax error since the interpreter recognizes that
both strings contain something that can be interpreted as
numbers (disregarding the spaces) and thus adds these two
numbers. And the result is the number 4.3. So the mistake
of using '+' instead of '.', made because you had written in
Python or C++ for the last hours where '+' is used for string
concatenation, gives a completely different result from what
you probably intended.

My point is that in these languages you have to learn quite
a large set of rules of how the interpreter will behave in
all kinds of situations. And many things that in a strongly
typed language would be syntax errors may have unexpected
meanings. That's not meant as a criticism of these languages
but just an observation that certain, quite nice-to-have
features come at a prize. And given that many people already
moan about the complexities of type promotions in C it might
be a bit of an unexpected steep learning curve when so many
other things look that simple in these languages.

                           xRegards, Jens
-- 
  \   Jens Thoms Toerring  ___      jt@toerring.de
   \__________________________      http://toerring.de

[toc] | [prev] | [next] | [standalone]

#63063

On 08/06/2015 10:42, Jens Thoms Toerring wrote:
> Bartc <bc@freeuk.com> wrote:

[Dynamic typing and scripting languages]
>> Actually, it makes it a bit harder to write, and the bytecode compiler,
>> if there is one, a bit easier. But writing source code becomes quicker
>> and easier too, which is the advantage.

> But the interpreter must follow certain rules. And some-
> times it follows different rules from what you might have
> expected. For example, in Perl you might attempt to ado
>
> $a  = ' 2.3 ';   # that's a string, isn't it?
> $a += '   2 ';   # this appends another string to it, doesn't it?
> print "$a\n";    # guess what this will print...
>
> Of course, this isn't a string concatenation (since in Perl
> you'd have to use the '.' operator for that). But it's also
> not a syntax error since the interpreter recognizes that
> both strings contain something that can be interpreted as
> numbers (disregarding the spaces) and thus adds these two
> numbers. And the result is the number 4.3. So the mistake
> of using '+' instead of '.', made because you had written in
> Python or C++ for the last hours where '+' is used for string
> concatenation, gives a completely different result from what
> you probably intended.
>
> My point is that in these languages you have to learn quite
> a large set of rules of how the interpreter will behave in
> all kinds of situations.

Not really. You have to learn that if you have two strings A and B, then 
A+B means string concatenation in some, and arithmetical add in others.

That doesn't take long. And making mistakes after switching languages 
occurs both ways.

> And many things that in a strongly
> typed language would be syntax errors may have unexpected
> meanings. That's not meant as a criticism of these languages
> but just an observation that certain, quite nice-to-have
> features come at a prize.

(I'm sure that's a Freudian slip rather than a typo...)

  And given that many people already
> moan about the complexities of type promotions in C it might
> be a bit of an unexpected steep learning curve when so many
> other things look that simple in these languages.

What would string concatenation look like in C? (Hint: it isn't just a 
called to strcat().)

There are huge benefits to being to just write A+B (or whatever the 
language uses) and let someone else worry about all the memory management.

Something else not often mentioned is that dynamic typing gives you 
generics and templates for free. Try writing a /single/ function sum() 
in C that takes an array of /any/ numeric type, of any length, and 
returns the sum of all the elements, and compare how elegant it looks 
compared to the dynamic version.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#63066

On Monday, June 8, 2015 at 11:28:27 AM UTC+1, Bart wrote:
> 
> There are huge benefits to being to just write A+B (or whatever the 
> language uses) and let someone else worry about all the memory management.
> 
> Something else not often mentioned is that dynamic typing gives you 
> generics and templates for free. Try writing a /single/ function sum() 
> in C that takes an array of /any/ numeric type, of any length, and 
> returns the sum of all the elements, and compare how elegant it looks 
> compared to the dynamic version.
> 
My view on this is that data consists mostly of integers, reals and strings, or compound
types built up of these elements. (That excludes the important case of graphs, but
that's a whole other kettle of fish).
Now if we operate on a list of numbers, and let's use a slightly less trivial function than
sum(), say standard deviation, then in C, you've got to get the data into the right format,
which will probably be an array of doubles, an integer N, and a flag for population or 
sample. But it's unlikely that data comes in like that. Most likely the program will be
reading a cdv file where the data series are in columns, maybe with missing entries,
and certainly with tags describing what the values actually mean. It's unlikely that you'll
need to support arbitrary-precision arithmetic, and, in this case at least, it's unlikely
that there's any value in using integer-only or single precision calculations for speed.

So, assuming, you don't want to rewrite the function, you've got to write a little adapter
function. This queries the CSV object for the number of entries in the column of interest,
calls malloc(), then goes through it extracting all the values and skipping over missing
data. Then it calls the standard deviation function, gets a double back, and converts it to
a string so the user can see the result.
So essentially the non-library, application specific code is reformatting data. It's very routine,
brain-dead programming. 

But the question is, is it really worth using advanced and confusing language features such
as templates, dynamic typing, and so on, to eliminate that donkey work? Does it really
gain you much, or does it just create new sources of errors? 

[toc] | [prev] | [next] | [standalone]

#63069

On Mon, 8 Jun 2015 05:10:43 -0700 (PDT), Malcolm McLean 
<malcolm.mclean5@btinternet.com> wrote:
> On Monday, June 8, 2015 at 11:28:27 AM UTC+1, Bart wrote:
> > 
> > There are huge benefits to being to just write A+B (or whatever 
the 
> > language uses) and let someone else worry about all the memory 
management.
> > 
> > Something else not often mentioned is that dynamic typing gives 
you 
> > generics and templates for free. Try writing a /single/ function 
sum() 
> > in C that takes an array of /any/ numeric type, of any length, 
and 
> > returns the sum of all the elements, and compare how elegant it 
looks 
> > compared to the dynamic version.
> > 
> My view on this is that data consists mostly of integers, reals and 
strings, or compound
> types built up of these elements. (That excludes the important case 
of graphs, but
> that's a whole other kettle of fish).
> Now if we operate on a list of numbers, and let's use a slightly 
less trivial function than
> sum(), say standard deviation, then in C, you've got to get the 
data into the right format,
> which will probably be an array of doubles, an integer N, and a 
flag for population or 
> sample. But it's unlikely that data comes in like that. Most likely 
the program will be
> reading a cdv file where the data series are in columns, maybe with 
missing entries,
> and certainly with tags describing what the values actually mean. 
It's unlikely that you'll
> need to support arbitrary-precision arithmetic, and, in this case 
at least, it's unlikely
> that there's any value in using integer-only or single precision 
calculations for speed.


> So, assuming, you don't want to rewrite the function, you've got to 
write a little adapter
> function. This queries the CSV object for the number of entries in 
the column of interest,
> calls malloc(), then goes through it extracting all the values and 
skipping over missing
> data. Then it calls the standard deviation function, gets a double 
back, and converts it to
> a string so the user can see the result.
> So essentially the non-library, application specific code is 
reformatting data. It's very routine,
> brain-dead programming. 


> But the question is, is it really worth using advanced and 
confusing language features such
> as templates, dynamic typing, and so on, to eliminate that donkey 
work? Does it really
> gain you much, or does it just create new sources of errors?

Well, you missed the point. If not serialized represantation of data, 
like csv is, there are no benefits of dynamic typing or templates. 
Only benefit would be generic function to calculate result while data 
is already converted. Other argument that one only needs doubles, is 
perhaps ok in your example but not in sum example. All in all c++ 
sort function is twice as fast than c qsort because of call overhead 
and c++ just inlines. That is other arhument, in this case for 
templates.

-- 
Press any key to continue or any other to quit 

[toc] | [prev] | [next] | [standalone]

#69880

In article <cthdk0Fnjb7U2@mid.uni-berlin.de>, jt@toerring.de says...
> 
> asetofsymbols@gmail.com wrote:
> > I imagine something as
> > a="1234asdfv"
> > b=1.564
> > c={1,2,3}{4,5,6}
> > a is a string
> > b is a number 
> > c is a 2x3 matrix
> > So if now I write
> > b=c
> > Than b is the matrix 
> > the same of c
> > And the memory store the value 1.564
> > is free.
> > This is like maple V and other math
> > language existing I saw in university.
> > One miss the original type when
> > there is one operator= 
> 
> >  is it better a type centric language as C, or C++ or better 
> > these "type free" languages?
> 
> There are lots of languages that don't care much about types,
> Python is probably one of the most commonly used at the moment.
> But, while a more-or-less type-agnostic language can be very
> nice for rapid prototyping, it has also its disadvantages:
> not having to define new variables or "cast" in assignments,
> it allows for bugs that, in strongly-typed language would
> have been caught at some stage (either by the compiler or
> the interpreter). So there have been diverging developments
> in the last decades. On the one hand, you have (mostly inter-
> preted) languages, that don't care too much about types, and
> which are mostly well-suited for fast development (and, also,
> for use by amateurs that can't be expected to understand the
> fine points of types) and languages (like e.g. ADA) that go
> into the exact opposite direction and are meant for mission-
> critical programs, where a single bug could kill lots of people
> (or cost millions) - so making it "harder" to write (buggy)
> programs is a huge benefit. C is something in between these
> two extremes.
> 
> Being a physicist by training and often dealing with data from
> acquiring and valuating data from experiments I'd sometimes love
> to have an even stronger-typed language that deals with units
> automatically (or would throw some kind of exception if, for
> example, the result of a multiplication of a voltage and a
> curent would be attempted to be stored in a variable that had
> not been defined as usable for a power only;-) Having different
> units converted automatically (e.g. from pounds to kg or feet
> to meters etc.) would be even better - that may have avoided
> losing an extremely expensive and irreplaceable spacecraft on
> Mars some years ago...
>                             Regards, Jens

As someone whose early background was in aerospace engineering, I agree 
with you that that would actually be a quite useful feature set for a 
programming language.  Might be a good thesis project for somebody.

[toc] | [prev] | [next] | [standalone]

#69914

On Tue, 8 Sep 2015 05:23:08 -0400, "J. Clarke"
<j.clarke.873638@gmail.com> wrote:

>In article <cthdk0Fnjb7U2@mid.uni-berlin.de>, jt@toerring.de says...
>> 
>> asetofsymbols@gmail.com wrote:
>> > I imagine something as
>> > a="1234asdfv"
>> > b=1.564
>> > c={1,2,3}{4,5,6}
>> > a is a string
>> > b is a number 
>> > c is a 2x3 matrix
>> > So if now I write
>> > b=c
>> > Than b is the matrix 
>> > the same of c
>> > And the memory store the value 1.564
>> > is free.
>> > This is like maple V and other math
>> > language existing I saw in university.
>> > One miss the original type when
>> > there is one operator= 
>> 
>> >  is it better a type centric language as C, or C++ or better 
>> > these "type free" languages?
>> 
>> There are lots of languages that don't care much about types,
>> Python is probably one of the most commonly used at the moment.
>> But, while a more-or-less type-agnostic language can be very
>> nice for rapid prototyping, it has also its disadvantages:
>> not having to define new variables or "cast" in assignments,
>> it allows for bugs that, in strongly-typed language would
>> have been caught at some stage (either by the compiler or
>> the interpreter). So there have been diverging developments
>> in the last decades. On the one hand, you have (mostly inter-
>> preted) languages, that don't care too much about types, and
>> which are mostly well-suited for fast development (and, also,
>> for use by amateurs that can't be expected to understand the
>> fine points of types) and languages (like e.g. ADA) that go
>> into the exact opposite direction and are meant for mission-
>> critical programs, where a single bug could kill lots of people
>> (or cost millions) - so making it "harder" to write (buggy)
>> programs is a huge benefit. C is something in between these
>> two extremes.
>> 
>> Being a physicist by training and often dealing with data from
>> acquiring and valuating data from experiments I'd sometimes love
>> to have an even stronger-typed language that deals with units
>> automatically (or would throw some kind of exception if, for
>> example, the result of a multiplication of a voltage and a
>> curent would be attempted to be stored in a variable that had
>> not been defined as usable for a power only;-) Having different
>> units converted automatically (e.g. from pounds to kg or feet
>> to meters etc.) would be even better - that may have avoided
>> losing an extremely expensive and irreplaceable spacecraft on
>> Mars some years ago...
>>                             Regards, Jens
>
>As someone whose early background was in aerospace engineering, I agree 
>with you that that would actually be a quite useful feature set for a 
>programming language.  Might be a good thesis project for somebody.


Boost::Units?

[toc] | [prev] | [next] | [standalone]

#63028

asetofsymbols@gmail.com writes:
> Yes it is possible to have a language
> without types...
> Than how easy represent
> struct name{
> Type1  name;
> Type2  name2;
> Etc
> };
> And find the errors in wrong type
> operator= call?

C is not a typeless language.  Why are you asking about typeless
languages in comp.lang.c?  Perhaps comp.lang.misc would be a better
place for your question.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#63056

On Saturday, June 6, 2015 at 3:56:37 PM UTC-5, Keith Thompson wrote:
> asetofsymbols@gmail.com writes:
> > Yes it is possible to have a language
> > without types...
> > Than how easy represent
> > struct name{
> > Type1  name;
> > Type2  name2;
> > Etc
> > };
> > And find the errors in wrong type
> > operator= call?
> 
> C is not a typeless language.  Why are you asking about typeless
> languages in comp.lang.c?  Perhaps comp.lang.misc would be a better
> place for your question.
> 

Without asserting that it helps any, it might interest
readers that the OP here was a cross-posted f-up to
a thread of mine in comp.lang.apl. Not really relevant
their either, though.

But I'm not trying to turn a fan into an enemy. Code-
trolls are different. They're wild, but they yield,
you know? They give back what they can do, and that's
what <deity> wants.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c

csiph-web