From: Randy Brukardt on
"Dmitry A. Kazakov" <mailbox(a)dmitry-kazakov.de> wrote in message
news:iv3qwjogornz$.1s8kq0yfl2wxl.dlg(a)40tude.net...
....
> Conversion mess is what we already have right now. The point is that "+"
> is
> well-defined and meaningful for octets, but it is not closed in there. Why
>
> function "**" (Left : T; Right : Natural) return T;
> function S'Pos(Arg : S'Base) return universal_integer;
> ...
>
> are OK and "+" is not?

The first has the same operand and result type (the power operand is
something else and not really part of the operator IMHO). The second is the
long winded name for a conversion operator - it implies no semantic change.
I'm arguing that operations like S'Pos would be better having a common name
like "#" rather than a host of specialized names.

>> Since we're inventing things, I would suggest:
>>
>> -- Conversion function (Not Ada):
>> function "#" (Right : Octet) return Universal_Integer;
>>
>> Little_Endian_Value := #Octet_1 + #Octet_2 * 256;
>>
>> And now you don't need any Octet math.
>
> 1. What is this else?

Huh? This doesn't parse.

> 2. I see no advantage over
>
> Little_Endian_Value := Integer (Octet_1) + Integer (Octet_2) * 256;

"#" can be overridden and/or user-defined. "Integer" cannot (and could never
be in a version of Ada, as any such attempt would be way too incompatible).
In addition, "#" is more readable in the 98% of the cases where you don't
need to specify a type. I would probably consider using predefined versions
of "#" to replace other forms of explicit type conversion as well (so "#"
would always work if defined - no decision about whether to call a function,
use a built-in type conversion, or use some attribute - and no need to look
up the name of the type).

>> BTW, the "#" operator was suggested by Jean Ichbiah and others back
>> during
>> the design of Ada 83, to be used for conversions between types. It's a
>> pity
>> that it or something like it never made it into Ada. (It comes up each
>> time
>> and still is rejected.)
>
> It would be nice to have more operators than now ("^", "|", "..", "in",
> ":=", "<>", "()", "[]", "{}", "<=>", "@", "~" and so on. Ah, Ada is
> Unicode
> now, here is the list: http://www.unicode.org/charts/PDF/U2200.pdf ).
>
> But what is so special in type conversions, aren't they just functions?

That's the point: in Ada, type conversions are *not* functions, they're a
built-in gizmo [including some attributed]; by naming them "#" we would
allow unifying them with functions. Of course, this could be abused (by
having some semantic change encoded in the function as well), but that of
course can happen just as well with "+" or "-" or "*".

Randy.


From: Randy Brukardt on
"Natacha Kerensikova" <lithiumcat(a)gmail.com> wrote in message
news:d1c9014b-c78c-4cb5-ae34-506f8e5702c7(a)i13g2000yqd.googlegroups.com...
....
>> ), then I assure you it can deal with Ada.
>
>But what's the point of knowing all this when one can't design a three-
>digit LOC program properly?
>It's just like knowing the dictionary contents by heart without
>knowing anything about grammar.

I think Bob's point is that most of this discussion is about software
engineering and program decomposition. That's orthogonal to the
implementation language: your programs would be better in any language, be
it C, Ada, Fortran, Pascal, or anything else when you (or anyone) take those
concepts into account.

But there is no *requirement* to take those concepts into account in order
to write Ada code. There is no requirement that you have to separate the
creation and writing of atoms. Your code would be better in *any* language
if you did, but it isn't always obvious how to accomplish that, and
depending on the situation, it might not be worth the mental effort to do
it.

In any case, you are spending way too much effort trying to figure out how
to fit your work into what Dmitry is suggesting. Bob and I have both tried
to point out that there are lots of other ways to structure programs over
what Dmitry is suggesting. Don't let one person's opinions push you away
from Ada!! There are a lot of strong opinions here, and not all of them are
the same. There is no one right way to use Ada!

Randy Brukardt, Editor, Ada 2005 and Ada 2012
Standards.



From: Robert A Duff on
"Randy Brukardt" <randy(a)rrsoftware.com> writes:

> I think Bob's point is that most of this discussion is about software
> engineering and program decomposition.

Thank you, Randy. Yes, exactly.

I don't think Natacha Kerensikova should be frightened away from Ada
just because of this discussion. I don't know if S-expressions with
untyped octet-sequence atoms are appropriate for some application
or other, but if they are, Natacha's design seems reasonable to me.
And that opinion is not specific to Ada.

- Bob
From: Dmitry A. Kazakov on
On Wed, 11 Aug 2010 18:18:48 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox(a)dmitry-kazakov.de> wrote in message
> news:iv3qwjogornz$.1s8kq0yfl2wxl.dlg(a)40tude.net...
> ...
>> Conversion mess is what we already have right now. The point is that "+"
>> is
>> well-defined and meaningful for octets, but it is not closed in there. Why
>>
>> function "**" (Left : T; Right : Natural) return T;
>> function S'Pos(Arg : S'Base) return universal_integer;
>> ...
>>
>> are OK and "+" is not?
>
> The first has the same operand and result type (the power operand is
> something else and not really part of the operator IMHO).

What is the difference between "**" and "+"? It must be a language one,
because semantically sum of octets is not an octet.

> The second is the
> long winded name for a conversion operator - it implies no semantic change.
> I'm arguing that operations like S'Pos would be better having a common name
> like "#" rather than a host of specialized names.

Huh, and these must be a type conversions too:

function S'Exponent (X : T) return universal_integer;
S'Length
A'Length (N)
...

>>> Since we're inventing things, I would suggest:
>>>
>>> -- Conversion function (Not Ada):
>>> function "#" (Right : Octet) return Universal_Integer;
>>>
>>> Little_Endian_Value := #Octet_1 + #Octet_2 * 256;
>>>
>>> And now you don't need any Octet math.
>>
>> 1. What is this else?
>
> Huh? This doesn't parse.

The above looks like math to me. You take octet arguments and compute some
results using arithmetic operations.

>> 2. I see no advantage over
>>
>> Little_Endian_Value := Integer (Octet_1) + Integer (Octet_2) * 256;
>
> "#" can be overridden and/or user-defined. "Integer" cannot (and could never
> be in a version of Ada, as any such attempt would be way too incompatible).
> In addition, "#" is more readable in the 98% of the cases where you don't
> need to specify a type. I would probably consider using predefined versions
> of "#" to replace other forms of explicit type conversion as well (so "#"
> would always work if defined - no decision about whether to call a function,
> use a built-in type conversion, or use some attribute - and no need to look
> up the name of the type).

I see. No, that is a wrong way IMO. The right one is interfaces. If you
want S be like T, derive S from T. If you don't like the implementation of
T, inherit only the interface of. You should never have a need in explicit
type conversions in a properly designed program.

> That's the point: in Ada, type conversions are *not* functions, they're a
> built-in gizmo [including some attributed]; by naming them "#" we would
> allow unifying them with functions.

I would prefer to eliminate them altogether. Conversions are always bad.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
From: Ludovic Brenta on
Georg Bauhaus wrote:
> On 10.08.10 17:48, Ludovic Brenta wrote:
>
>> I've corrected that and rewritten test.adb to use your example:
>>
>> (tcp-connection ((host foo.bar) (port 80)))
>>
>> My parser needs still the above syntax and will not accept the
>> theoretically equivalent
>>
>> (tcp-connection (host foo.bar) (port 80))
>>
>> yet.
>
> How does it handle
> (tcp-connection ((host foo.bar) (port 80))
> (tcp-connection ((host abc.xyz) (port 80)))

I made some fixes and I now consider my S-Expression parser[1] feature-
complete as of revision b13ccabbaf227bad264bde323138910751aa2c2b.
There may still be some bugs though, and the error reporting (to
diagnose syntax errors in the input) is very primitive.

Highlights:
* the procedure S_Expression.Read is a quasi-recursive descent
parser. "Quasi" because it only recurses when encountering an opening
parenthesis, but processes atoms without recursion, in the same finite
state machine.
* the parser reads each character exactly once; there is no push_back
or backtracking involved. This makes the parser suitable to process
standard input on the fly.
* to achive this, I had to resort to using exceptions instead of
backtracking; this happens when the parser encounters a ')'
immediately after an S-Expression (atom or list).
* the parser also supports lists of the form (a b c) (more than 2
elements) and properly translates them to (a (b c)). The Append()
procedure that does this is also public and available to clients.
* the parser does not handle incomplete input well. If it gets
Ada.IO_Exceptions.End_Error in the middle of an S-Expression, it will
return an incomplete, possibly empty, S-Expression rather than report
the error. I'll try to improve that.
* the test.adb program demonstrates how to construct an S-Expression
tree in memory (using cons()) and then sending it to a stream (using
'Write).
* the test.adb program also demonstrates how to read an S-Expression
from a stream (using 'Read) and then traverse the in-memory tree
(using car(), cdr()).

[1] http://green.ada-france.org:8081/branch/changes/org.ludovic-brenta.s_expressions

I have not yet tested the parser on your proposed input (IIUC,
consisting of two S-Expressions with a missing closing parenthesis).
I think this will trigger the bug where End_Error in the middle of an
S-Expression is not diagnosed.

I also still need to add the proper GPLv3 license text on each file.

I'll probably add support for Lisp-style comments (starting with ';'
and ending at end of line) in the future.

--
Ludovic Brenta.
First  |  Prev  |  Next  |  Last
Pages: 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33
Prev: GPRbuild compatibility
Next: Irony?