June 24, 2005
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
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
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
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
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
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