View mode: basic / threaded / horizontal-split · Log in · Help
June 24, 2005
Re: Array indexing & typedef :: warning, slightly long
Regan Heath wrote:
> After a brief look I'm not quite sure where to start.
> 
> I see Symbols  (the container class)
> I see Symbol   (created to hold a Token, and SymbolId)
> I see Token    (an object)
> I see SymbolId (ever incrementing, always unique id for a Symbol)
> I see IndexId  (not used?)
> 
> You said "But I'd need to write it several times", what parts change 
> for  the next time?
> 
> Regan
O, there are predicates, and rules, and various indexes...I'm not 
sure whatall as I'm still translating (and understanding) the 
original program.  Certainly I won't be doing things quite the 
same way, as the original includes a manually implemented hash 
table and tree structure, and there are pointers all over the 
place. (I have a fierce distaste for having to deal with 
pointers.  That's the compiler's job!)  It also includes storage 
management without including garbage collection.  I'm certain 
that parts of what I'm not understanding have to do with that.  Etc.

As near as I can tell the guy who wrote it was more a professor 
of Computer Science specializing in AI than a programmer.  I feel 
certain that Ada COULD be done more neatly.  (OTOH, without 
understanding exactly what he's doing in places, this is a bit of 
a non-humble analysis...but, e.g., he implemented his own 
variable length strings claiming that Ada didn't provide them. 
But perhaps they were added with Ada95, and he was writing for 
Ada 198x.)

Anyway understanding the program is one challenge, and 
translating it into a modern decent language is another.  And 
when I get done I'll have a toy backward chaining Expert System 
Shell.  (I'll probably also change the syntax of the rules...but 
first I need to understand what he was doing with them 
originally...and that requires understanding the program. :) I'm 
finding the combination to be quite an interesting challenge.)

P.S.:  SymbolId, TokenId, PredicateId, RuleId, etc. are all my 
idea.  The original used pointers in these places, but I want 
something that I can reasonably store in a database.  Id's are 
permanent, memory locations are transient.  This means that it's 
going to be a bit difficult to forget things, since I won't be 
able to depend on a garbage collector, but it's worth the price 
to be able to checkpoint dump a process, and then resume later 
without worrying about relocation in memory.
June 24, 2005
Re: Array indexing & typedef :: warning, slightly long
Derek Parnell wrote:
> On Thu, 23 Jun 2005 17:00:25 -0700, Charles Hixson wrote:
> 
> 
> [snip]
>> OK, here it is.  Note that I had to define append rather than 
>> using optCatAssign, and I have to call optIndex as a function 
>> rather than using [] access.
> 
> Should be "op" rather than "opt". However the opCatAssign() will not work
> until Walter allows us to concatenate things that are not arrays. If you
> define opCatAssign() and then use "x ~= y" where 'y' is not an array or an
> element of 'x', the compiler complains.
>[snip]

Thanks much for the analysis.  At least that tells me:
1) How to fix MY mistake and
2) Why the thing that wasn't my mistake didn't work.  I do hope 
that SOME better way to append to a container class soon becomes 
available.  opCatAssign seemed the most reasonable, but if not 
that, then some other.  Otherwise user container classes will 
remain...kludgy.  (You don't happen to know if allowing this is 
planned for the future, do you?)
June 24, 2005
Re: Array indexing & typedef :: warning, slightly long
On Fri, 24 Jun 2005 00:00:19 -0700, Charles Hixson wrote:

> Derek Parnell wrote:
>> ... the opCatAssign() will not work
>> until Walter allows us to concatenate things that are not arrays. If you
>> define opCatAssign() and then use "x ~= y" where 'y' is not an array or an
>> element of 'x', the compiler complains.

> ...  (You don't happen to know if allowing this is 
> planned for the future, do you?)

No I don't. It seems a sensible idea to a mere mortal like myself but
Walter doesn't always see things the same way that I do ;-)

In my opinion, the general case of ...

 <classinstance> ~= <expression>

should call 

  <classinstance>.opCatAssign( <expression> )

if there is a matching member defined. This should also apply to structs as
well. My rationale is that it if such a member is defined then the class
(or struct) knows what to do with the <expression> so the compiler should
just let it do its thing.

I hope that this is just an oversight and will be fixed very soon.

-- 
Derek
Melbourne, Australia
24/06/2005 5:12:01 PM
June 24, 2005
Re: Array indexing & typedef :: warning, slightly long
Charles Hixson wrote:

> other.  Otherwise user container classes will remain...kludgy.  (You 
> don't happen to know if allowing this is planned for the future, do you?)
> 

What's so kludgy? I don't see any difference between:

x ~= y

and

x.append(y);

Less typing with the operator, particularly for chaining, but the same 
result either way. I prefer the latter, actually. To me the ~ operator 
in D means 'concat 2 arrays'. Once you start allowing it to be 
overloaded, it could mean anything. Then you wind up with cryptic code 
where you constantly have to look up the overide to make sure it really 
is appending/concatting and not doing something funky. It's like when 
people use the * operator with two vectors to carry out a dot product. 
Always throws me off. I would be happy if Walter did away with operator 
overloading altogether, but that's just wishful thinking :)
June 24, 2005
Re: Array indexing & typedef :: warning, slightly long
On Fri, 24 Jun 2005 16:45:49 +0900, Mike Parker wrote:

> Charles Hixson wrote:
> 
>> other.  Otherwise user container classes will remain...kludgy.  (You 
>> don't happen to know if allowing this is planned for the future, do you?)
>> 
> 
> What's so kludgy? I don't see any difference between:
> 
> x ~= y
> 
> and
> 
> x.append(y);
> 
> Less typing with the operator, particularly for chaining, but the same 
> result either way. I prefer the latter, actually. To me the ~ operator 
> in D means 'concat 2 arrays'.

I understand your point of view. To me "~" means "concat 2 things
together". 

> Once you start allowing it to be 
> overloaded, it could mean anything. Then you wind up with cryptic code 
> where you constantly have to look up the overide to make sure it really 
> is appending/concatting and not doing something funky. It's like when 
> people use the * operator with two vectors to carry out a dot product. 
> Always throws me off. I would be happy if Walter did away with operator 
> overloading altogether, but that's just wishful thinking :)

Yes, this is an issue with overloading operators, but on the other hand,
how do you know that a function called 'append' is also not doing anything
'funky'? It might not even be appending. Its the same argument really.

-- 
Derek
Melbourne, Australia
24/06/2005 6:52:24 PM
June 24, 2005
Re: Array indexing & typedef :: warning, slightly long
Derek Parnell wrote:

> Yes, this is an issue with overloading operators, but on the other hand,
> how do you know that a function called 'append' is also not doing anything
> 'funky'? It might not even be appending. Its the same argument really.
> 
Not entirely the same argument. When you see an operator, your mind is 
trained to recognize it as a specific functions. '+' generally means 
'add' and '-' generally means 'subtract'. This is built in to the 
language do fundamentally never changes. Function names and 
implementations *do* vary from API to API and generally require that you 
read the documentation and/or source to completely understand what any 
given function does. So when I'm skimming source, a '+' operator 
registers as 'addition' automatically and the eyes move on, but a 
function named 'add' registers no differently than a function named 
'googleyfoobob' - both being functions, they will definitely stand out 
if I don't already know exactly what they do, particularly when debugging.
Next ›   Last »
1 2 3
Top | Discussion index | About this forum | D home